Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On Tue, Sep 30, 2014 at 6:25 PM, William Dunlap wrote: > In S+ and S it was valid to pass logicals to .Fortran, where they got > mapped into the > appropriate bit pattern. (The trouble was that 'appropriate' was > compiled into the program - > so you were locked into our compiler vendor's choice). Passing them > between Fortran > code and C code has always been a problem (as has passing character > data between them). > That makes sense. The code was originally written for S-plus, and the accompanying R code is still in files with a .S extension The maintainer has now fixed it. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Shallow copies
On Sep 30, 2014, at 5:20 PM, Matthieu Gomez wrote: > > I have a question about shallow copies in R. Since R 3.1.0, subsetting a > dataframe with respect to its columns no longer result in deep copies. This > is an amazing change in my opinion. Now, subsetting a data.frame by rows (or > subsetting a matrix by columns or rows) still does deep copies. In > particular, it is my understanding that running a command on a very large > subset of rows (say "sum" or "biglm" on non outliers observations) results in > a deep copy of these rows first, which can require twice as much the memory > of the original data.frame/matrix. If this is correct, I would be very > interested to know more on whether this behavior can/may change in future > versions of R. > No. Subsetting a vector always requires a copy by definition*. Each column in a dataframe and each matrix is a vector, so any subset thereof always requires a copy no matter what you do. Subsetting columns of a dataframe only requires a copy of the dataframe vector itself which is small by comparison (at least for datasets that use data frames). Cheers, Simon * - you could try to do tricks where you fake a copy with things like COW mmaps, but you still need to have a copy conceptually. There are other tricks like deferred execution (you don't actually compute the result but only store the recipe for creating it), but those are more specialized and not generally available. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] gsl package on mavericks
hello
I maintain the gsl R package, and many users have recently reported that
the package
does not install from source under macosx 10.9 ("mavericks").
Users typically install the gnu GSL library and are able to compile and run
a small "hello world" program which executes some of the Bessel functionality
of the library; but under mavericks the configure script (which uses
gsl-config as a probe) does not seem to detect which version of the
installed library is, giving a "Need GSL version >= 1.12" error. The most
recent version of the gnu GSL library is 1.16.
The CRAN package check page shows that the gsl R package is clean under
every other architecture.
There is a thread on stackoverflow about this very issue:
http://stackoverflow.com/questions/24781125/installing-r-gsl-package-on-mac
where several people post either workarounds or suggestions. However, it
is not clear whether there is some defect in the configure.ac script, or
the problem is due to mavericks, or it might even lie in newer versions of
the gnu GSL library.
The package gsl_1.9-10.tar.gz installs correctly from source for me on my
system, macosx 10.9.4, R-3.1.1, GSL-1.16, so it is difficult for me to
investigate users' reports.
Can anyone advise?
--
Robin Hankin
Neutral theorist
hankin.ro...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gsl package on mavericks
I have only skimmed this issue. But you check gsl version by compiling a
program with
#include
This assumes, as far as I can see, that gsl/gsl.h is in the search path (I
know, it is the wrong technical term) of the compiler, which may not be the
case for a non-standard installation. Above this code you end up with a
variable called GSL_CFLAGS. Somehow, I would expect that the test program
has to be compiled using the settings revealed by GSL_CFLAGS, but I don't
see that happening (I am not an expert on autoconf, so it may happen behind
the scenes). I think you need to somehow pass GSL_CFLAGS to AC_LANG_SOURCE.
This seems consistent with the reports on SO, where some people are using
brew which installs it in a location not part of the standard search path,
I think.
Best,
Kasper
On Wed, Oct 1, 2014 at 4:58 PM, robin hankin wrote:
> hello
>
> I maintain the gsl R package, and many users have recently reported that
> the package
> does not install from source under macosx 10.9 ("mavericks").
>
> Users typically install the gnu GSL library and are able to compile and run
> a small "hello world" program which executes some of the Bessel
> functionality
> of the library; but under mavericks the configure script (which uses
> gsl-config as a probe) does not seem to detect which version of the
> installed library is, giving a "Need GSL version >= 1.12" error. The most
> recent version of the gnu GSL library is 1.16.
>
> The CRAN package check page shows that the gsl R package is clean under
> every other architecture.
>
> There is a thread on stackoverflow about this very issue:
>
> http://stackoverflow.com/questions/24781125/installing-r-gsl-package-on-mac
>
> where several people post either workarounds or suggestions. However, it
> is not clear whether there is some defect in the configure.ac script, or
> the problem is due to mavericks, or it might even lie in newer versions of
> the gnu GSL library.
>
> The package gsl_1.9-10.tar.gz installs correctly from source for me on my
> system, macosx 10.9.4, R-3.1.1, GSL-1.16, so it is difficult for me to
> investigate users' reports.
>
>
> Can anyone advise?
>
>
> --
> Robin Hankin
> Neutral theorist
> hankin.ro...@gmail.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
