Re: [Rd] FreeBSD 7.0-CURRENT and R-2.2.0 alpha
Sorry for my very late answer. On Sept. 12th I got an unexpected business trip until yesterday evening, so I had no chance to try out. Thank you for the hints. But I am afraid I have no idea how to extract the needed information. With R-2.2.0 (R-beta_2005-09-22_r35658.tar.gz) I tried the following: nm /usr/lib/libc.a | grep cpow nm /usr/lib/libm.a | grep cpow In both cases without any result. Where I have to look? Or what else can I do to find out where the libs with these procedures are? Rainer Hurling Prof Brian Ripley wrote: > These were found by AC_CHECK_FUNCS (please confirm what configure said) > so most likely some macro needs to be set or header included. > > Could you please find out how configure managed to find cpow etc when > they appear not to be in libc/libm? > > On Sat, 10 Sep 2005, Rainer Hurling wrote: > >> The configure script runs fine, but when I compile todays alpha version >> of R-2.2.0 (R-alpha_2005-09-10_r35546.tar.gz) under FreeBSD 7.0-CURRENT >> from Sept. 4th I get the following output: >> >> >> >> [...] >> gcc -I../../src/extra/zlib -I../../src/extra/bzip2 >> -I../../src/extra/pcre -I. -I../../src/include -I../../src/include >> -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -O2 -c >> version.c -o version.o >> gcc -I../../src/extra/zlib -I../../src/extra/bzip2 >> -I../../src/extra/pcre -I. -I../../src/include -I../../src/include >> -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -g -O2 -c >> vfonts.c -o vfonts.o >> f77 -g -O2 -c xxxpr.f -o xxxpr.o >> gcc -export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o >> CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o >> apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o >> colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o >> debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o >> engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o >> gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o >> logic.o main.o mapply.o match.o memory.o model.o names.o objects.o >> optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o >> plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o >> qsort.o random.o regex.o registration.o relop.o saveload.o scan.o seq.o >> serialize.o size.o sort.o source.o split.o sprintf.o startup.o >> subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o >> version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a >> ../nmath/libnmath.a -lf77blas -latlas -lg2c -lm ../extra/zlib/libz.a >> ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a >> /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib -lreadline -lm >> -liconv >> complex.o(.text+0x106): In function `mycpow': >> /usr/local/R-alpha/src/main/complex.c:170: undefined reference to `cpow' >> complex.o(.text+0x6f9): In function `do_cmathfuns': >> /usr/local/R-alpha/src/main/complex.c:323: undefined reference to `carg' >> complex.o(.text+0xb4b): In function `z_log': >> /usr/local/R-alpha/src/main/complex.c:423: undefined reference to `clog' >> complex.o(.text+0xb86): In function `z_logbase': >> /usr/local/R-alpha/src/main/complex.c:429: undefined reference to `clog' >> complex.o(.text+0xb98):/usr/local/R-alpha/src/main/complex.c:429: >> undefined reference to `clog' >> complex.o(.text+0xbd8): In function `z_exp': >> /usr/local/R-alpha/src/main/complex.c:434: undefined reference to `cexp' >> complex.o(.text+0xbf8): In function `z_sqrt': >> /usr/local/R-alpha/src/main/complex.c:439: undefined reference to `csqrt' >> complex.o(.text+0xc18): In function `z_cos': >> /usr/local/R-alpha/src/main/complex.c:486: undefined reference to `ccos' >> complex.o(.text+0xc38): In function `z_sin': >> /usr/local/R-alpha/src/main/complex.c:491: undefined reference to `csin' >> complex.o(.text+0xc5e): In function `z_tan': >> /usr/local/R-alpha/src/main/complex.c:497: undefined reference to `ctan' >> complex.o(.text+0xd26): In function `z_atan2': >> /usr/local/R-alpha/src/main/complex.c:523: undefined reference to `catan' >> complex.o(.text+0xe18): In function `z_asin': >> /usr/local/R-alpha/src/main/complex.c:541: undefined reference to `casin' >> complex.o(.text+0xe38): In function `z_acos': >> /usr/local/R-alpha/src/main/complex.c:553: undefined reference to `cacos' >> complex.o(.text+0xe58): In function `z_atan': >> /usr/local/R-alpha/src/main/complex.c:559: undefined reference to `catan' >> complex.o(.text+0xe78): In function `z_acosh': >> /usr/local/R-alpha/src/main/complex.c:564: undefined reference to >> `cacosh' >> complex.o(.text+0xe98): In function `z_asinh': >> /usr/local/R-alpha/src/main/complex.c:569: undefined reference to >> `casinh' >> complex.o(.text+0xeb8): In function `z_atanh': >> /usr/local/R-alpha/src/main/complex.c:574: undefined reference to >> `catanh' >> complex.o(.text+0xed8): In function `z_cosh': >> /
[Rd] plot, spineplot, boxplot in R 2.2.0
I noticed, what seened to me, to be odd. These produce a boxplot in the first case and a spineplot in the second case in R .2.2.0: plot(Sepal.Length ~ Species, iris) plot(Species ~ Sepal.Length, iris) What if one wants to exchange axes? Does the fact that this seemingly innocuous change result in completely different graphics make sense? Is it desirable? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] complex.h in R
Hi, How does complex.h used in R? Whether a compiler support complex.h or not, does it affect R's performance? I used PGI compiler to build R-devel on AMD Opteron, but the configuration file failed to link BLAS library despite the fact it is located in the usual location, /usr/lib64. PGI said they don't support complex.h. R configuration script printed out that doublecomplex is not supported. Are "supporting complex.h" and "linking BLAS library" related? any comments on this issue? note: I can ignore linking BLAS and proceed to compile R with PGI compiler successfully. Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot, spineplot, boxplot in R 2.2.0
I agree that I was mixing up the two issues. On 9/24/05, John Fox <[EMAIL PROTECTED]> wrote: > Dear Gabor, > > This behaviour makes sense to me, since in the first case the response is > quantitative and the explanatory variable a factor (hence, parallel > boxplots), while in the second it's vice-versa (hence parallel stacked > bars). That is, the primary distinction, I think, isn't the orientation of > the axes but the nature of the variables. > > Regards, > John > > > John Fox > Department of Sociology > McMaster University > Hamilton, Ontario > Canada L8S 4M4 > 905-525-9140x23604 > http://socserv.mcmaster.ca/jfox > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Gabor Grothendieck > > Sent: Saturday, September 24, 2005 10:49 AM > > To: R-devel > > Subject: [Rd] plot, spineplot, boxplot in R 2.2.0 > > > > I noticed, what seened to me, to be odd. These produce a > > boxplot in the first case and a spineplot in the second case > > in R .2.2.0: > > > > plot(Sepal.Length ~ Species, iris) > > plot(Species ~ Sepal.Length, iris) > > > > What if one wants to exchange axes? Does the fact that this > > seemingly innocuous change result in completely different > > graphics make sense? Is it desirable? > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot, spineplot, boxplot in R 2.2.0
On 9/24/05, Marc Schwartz <[EMAIL PROTECTED]> wrote: > On Sat, 2005-09-24 at 11:48 -0400, Gabor Grothendieck wrote: > > I noticed, what seened to me, to be odd. These produce > > a boxplot in the first case and a spineplot in the second > > case in R .2.2.0: > > > > plot(Sepal.Length ~ Species, iris) > > plot(Species ~ Sepal.Length, iris) > > > > What if one wants to exchange axes? Does the fact that > > this seemingly innocuous change result in completely > > different graphics make sense? Is it desirable? > > Gabor, > > Did you try: > > plot(Sepal.Length ~ Species, iris, horizontal = TRUE) I had tried horiz= which did not have any effect but I should have written it all out since it comes after a ... . In any case it works as you have shown but not if I interchange the variables. > > This will rotate the boxplot by 90 degrees, as expected. > > The plot method is dispatched based upon (from ?plot.formula): > > If y is an object (i.e. has a class attribute) then plot.formula looks > for a plot method for that class first. Otherwise, the class of x will > determine the type of the plot. For factors this will be a parallel > boxplot, and argument horizontal = TRUE can be used (see boxplot). > > > Since there is no plot.numeric(), plot.factor() will be used. > > This is unchanged from 2.1.1. > > What is changed is the plot that is created in your second case. In > 2.1.1, this was a barplot, rather than a spineplot. From > 2.1.1 ?plot.factor: > > This functions implements a "scatterplot" method for factor arguments of > the generic plot function. Actually, boxplot or barplot are used when > appropriate. > > > >From 2.0.0 beta ?plot.factor: > > This functions implements a "scatterplot" method for factor arguments of > the generic plot function. Actually, boxplot is used when y is numeric > and a spineplot when y is a factor. For a single factor x (i.e., with y > missing) a simple barplot is produced. > > > > HTH, > > Marc Schwartz > > > OK. Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot, spineplot, boxplot in R 2.2.0
Dear Gabor, This behaviour makes sense to me, since in the first case the response is quantitative and the explanatory variable a factor (hence, parallel boxplots), while in the second it's vice-versa (hence parallel stacked bars). That is, the primary distinction, I think, isn't the orientation of the axes but the nature of the variables. Regards, John John Fox Department of Sociology McMaster University Hamilton, Ontario Canada L8S 4M4 905-525-9140x23604 http://socserv.mcmaster.ca/jfox > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gabor Grothendieck > Sent: Saturday, September 24, 2005 10:49 AM > To: R-devel > Subject: [Rd] plot, spineplot, boxplot in R 2.2.0 > > I noticed, what seened to me, to be odd. These produce a > boxplot in the first case and a spineplot in the second case > in R .2.2.0: > > plot(Sepal.Length ~ Species, iris) > plot(Species ~ Sepal.Length, iris) > > What if one wants to exchange axes? Does the fact that this > seemingly innocuous change result in completely different > graphics make sense? Is it desirable? > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot, spineplot, boxplot in R 2.2.0
On Sat, 2005-09-24 at 12:00 -0500, Marc Schwartz wrote: > >From 2.0.0 beta ?plot.factor: Ack...That should be 2.2.0 beta. Sorry for the typo. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot, spineplot, boxplot in R 2.2.0
On Sat, 2005-09-24 at 11:48 -0400, Gabor Grothendieck wrote: > I noticed, what seened to me, to be odd. These produce > a boxplot in the first case and a spineplot in the second > case in R .2.2.0: > > plot(Sepal.Length ~ Species, iris) > plot(Species ~ Sepal.Length, iris) > > What if one wants to exchange axes? Does the fact that > this seemingly innocuous change result in completely > different graphics make sense? Is it desirable? Gabor, Did you try: plot(Sepal.Length ~ Species, iris, horizontal = TRUE) This will rotate the boxplot by 90 degrees, as expected. The plot method is dispatched based upon (from ?plot.formula): If y is an object (i.e. has a class attribute) then plot.formula looks for a plot method for that class first. Otherwise, the class of x will determine the type of the plot. For factors this will be a parallel boxplot, and argument horizontal = TRUE can be used (see boxplot). Since there is no plot.numeric(), plot.factor() will be used. This is unchanged from 2.1.1. What is changed is the plot that is created in your second case. In 2.1.1, this was a barplot, rather than a spineplot. From 2.1.1 ?plot.factor: This functions implements a “scatterplot” method for factor arguments of the generic plot function. Actually, boxplot or barplot are used when appropriate. >From 2.0.0 beta ?plot.factor: This functions implements a “scatterplot” method for factor arguments of the generic plot function. Actually, boxplot is used when y is numeric and a spineplot when y is a factor. For a single factor x (i.e., with y missing) a simple barplot is produced. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] complex.h in R
On Sat, 24 Sep 2005, Jennifer Lai wrote: > Hi, > How does complex.h used in R? Whether a compiler support complex.h > or not, does it affect R's performance? complex.h will only used in future (2.2.0-to-be) versions of R, and only if configure finds enough C99 support. Otherwise R's own C-level complex support is used, as it always was. One would expect the OS's support to be faster and more accurate (but one could be disappointed, we have found). > I used PGI compiler to build > R-devel on AMD Opteron, but the configuration file failed to link BLAS > library despite the fact it is located in the usual location, > /usr/lib64. Look in config.log to find out why. > PGI said they don't support complex.h. R configuration > script printed out that doublecomplex is not supported. That is *FORTRAN* DOUBLE COMPLEX, and that does affect the operation of R, as without it you will not have complex linear algebra support. > Are "supporting > complex.h" and "linking BLAS library" related? No. They are completely orthoogonal concepts. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel