Re: [Rd] sapply(Date, is.numeric)
I've now committed fixes in R-patched and R-devel. There is one consequence: data.matrix() was testing for numeric columns by unlist(lapply(x, is.numeric)) and so incorrectly treating Date and POSIXct columns as numeric (which we had decided they were not). This affects package gvlma. data.matrix() is now working as documented, but as we have an exception for factors, do we also want exceptions for Date and POSIXct? On Wed, 30 Jul 2008, Martin Maechler wrote: "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> on Wed, 30 Jul 2008 13:29:38 +0100 (BST) writes: BDR> On Wed, 30 Jul 2008, Martin Maechler wrote: >>> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> >>> on Tue, 29 Jul 2008 15:40:37 -0400 writes: >> RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, >> >> [... r-bugs problems discussed in a separate thread ] >> >> >> RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> >> >> x <- data.frame(dt=Sys.Date()) >> >> is.numeric(x$dt) RobMcG> [1] FALSE >> >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE >> RobMcG> ## Yet, sapply seems aware of the Date class >> >> sapply(x, class) RobMcG> dt RobMcG> "Date" >> >> Yes, thanks a lot, Robert, for the report. >> >> That *is* a bug somewhere in the .Internal(lapply(...)) C code, >> when S3 dispatch of primitive functions should happen. BDR> The bug is in do_is, which uses CHAR(PRINTNAME(CAR(call))), and when BDR> called from lapply that gives "FUN" not "is.numeric". The root cause is BDR> the following comment BDR> FUN = CADR(args); /* must be unevaluated for use in e.g. bquote */ BDR> and hence that the function in the *call* passed to do_is can be BDR> unevaluated. aah! I see. >> Here's an R scriptlet exposing a 2nd example >> >> ### lapply(list, FUN) >> ### -- seems to sometimes fail for >> ### .Primitive S3-generic functions >> >> (ds <- seq(from=Sys.Date(), by=1, length=4)) >> ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> ll <- list(d=ds) >> lapply(list(d=ds), round) >> ## -> Error in lapply(list(d = ds), round) : dispatch error BDR> And that's a separate issue, in DispatchGroup which states that arguments BDR> have been evaluated (true) but the 'call' from lapply gives the BDR> unevaluated arguments and so there is a mismatch. yes, I too found that this was a separate issue, the latter one being new since version 2.7.0 BDR> I'm testing fixes for both. Excellent! Martin >> ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: >> sapply(list(d=ds), is.numeric) >> ## TRUE >> >> ## in spite of >> is.numeric(`[[`(ll,1)) ## FALSE , because of >> is.numeric.date >> >> ## or >> round(`[[`(ll,1)) >> ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> >> ##- >> >> But I'm currently too much tied up with other duties, >> to find and test bug-fix. >> >> Martin Maechler, ETH Zurich and R-Core Team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric)
> "PBR" == Prof Brian Ripley <[EMAIL PROTECTED]> > on Thu, 31 Jul 2008 08:36:22 +0100 (BST) writes: PBR> I've now committed fixes in R-patched and R-devel. PBR> There is one consequence: data.matrix() was testing for numeric columns by PBR> unlist(lapply(x, is.numeric)) and so incorrectly treating Date and POSIXct PBR> columns as numeric (which we had decided they were not). This affects PBR> package gvlma. PBR> data.matrix() is now working as documented, but as we have an exception PBR> for factors, do we also want exceptions for Date and POSIXct? Yes, that's a good idea, and much in the spirit of data.matrix() as I have understood it. Note the following from help(data.matrix) where I think the 'Title' and 'Description' are more liberal (rightly so) than 'Details' : >> Convert a Data Frame to a Numeric Matrix >> >> Description: >> >> Return the matrix obtained by converting all the variables in a >> data frame to numeric mode and then binding them together as the >> columns of a matrix. Factors and ordered factors are replaced by >> their internal codes. [...] >> Details: >> >> Supplying a data frame with columns which are not numeric, factor >> or logical is an error. A warning is given if any non-factor >> column has a class, as then information can be lost. Do we really have good reasons to give an error if a column is not numeric (nor of the "exception class")? Couldn't we just lapply(., as.numeric) and if that doesn't give errors just "be happy" ? Martin PBR> On Wed, 30 Jul 2008, Martin Maechler wrote: >>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> >>> on Wed, 30 Jul 2008 13:29:38 +0100 (BST) writes: >> BDR> On Wed, 30 Jul 2008, Martin Maechler wrote: >> >>> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> >> >>> on Tue, 29 Jul 2008 15:40:37 -0400 writes: >> >> RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, >> >> >> >> [... r-bugs problems discussed in a separate thread ] >> >> >> >> >> >> RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> >> >> >> >> x <- data.frame(dt=Sys.Date()) >> >> >> is.numeric(x$dt) RobMcG> [1] FALSE >> >> >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE >> >> RobMcG> ## Yet, sapply seems aware of the Date class >> >> >> sapply(x, class) RobMcG> dt RobMcG> "Date" >> >> >> >> Yes, thanks a lot, Robert, for the report. >> >> >> >> That *is* a bug somewhere in the .Internal(lapply(...)) C code, >> >> when S3 dispatch of primitive functions should happen. >> BDR> The bug is in do_is, which uses CHAR(PRINTNAME(CAR(call))), and when BDR> called from lapply that gives "FUN" not "is.numeric". The root cause is BDR> the following comment >> BDR> FUN = CADR(args); /* must be unevaluated for use in e.g. bquote */ >> BDR> and hence that the function in the *call* passed to do_is can be BDR> unevaluated. >> >> aah! I see. >> >> >> Here's an R scriptlet exposing a 2nd example >> >> >> >> ### lapply(list, FUN) >> >> ### -- seems to sometimes fail for >> >> ### .Primitive S3-generic functions >> >> >> >> (ds <- seq(from=Sys.Date(), by=1, length=4)) >> >> ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> >> ll <- list(d=ds) >> >> lapply(list(d=ds), round) >> >> ## -> Error in lapply(list(d = ds), round) : dispatch error >> >> BDR> And that's a separate issue, in DispatchGroup which states that arguments BDR> have been evaluated (true) but the 'call' from lapply gives the BDR> unevaluated arguments and so there is a mismatch. >> >> yes, I too found that this was a separate issue, the latter >> one being new since version 2.7.0 >> BDR> I'm testing fixes for both. >> >> Excellent! >> Martin >> >> >> >> ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: >> >> sapply(list(d=ds), is.numeric) >> >> ## TRUE >> >> >> >> ## in spite of >> >> is.numeric(`[[`(ll,1)) ## FALSE , because of >> >> is.numeric.date >> >> >> >> ## or >> >> round(`[[`(ll,1)) >> >> ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> >> >> >> ##- >> >> >> >> But I'm currently too much tied up with other duties, >> >> to find and test bug-fix. >> >> >> >> Martin Maechler, ETH Zurich and R-Core Team >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> PBR> --
Re: [Rd] R, Macports and C++ streams
Ernest, Is it possible to provide a reproducible example of your crash? Kjell On Jul 30, 2008, at 6:32 PM, Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Cheers, Ernest Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C versions of serialize/unserialize in packages
Are the functions 'R_Unserialize' and 'R_InitFileInPStream' allowed to be used in R packages? I guess I'm just not clear on the implications of this comment in 'Rinternals.h': /* The connection interface is not yet available to packages. To allow limited use of connection pointers this defines the opaque pointer type. */ I have a function in the 'filehash' package that unserializes a bunch of objects from a file and it seems to run much faster in C than in R. But I don't want to release something that uses a non-public function/interface. Thanks, -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C versions of serialize/unserialize in packages
Hi, On Thu, Jul 31, 2008 at 6:35 AM, Roger D. Peng <[EMAIL PROTECTED]> wrote: > Are the functions 'R_Unserialize' and 'R_InitFileInPStream' allowed to > be used in R packages? I guess I'm just not clear on the implications > of this comment in 'Rinternals.h': > > /* The connection interface is not yet available to packages. To > allow limited use of connection pointers this defines the opaque > pointer type. */ > > I have a function in the 'filehash' package that unserializes a bunch > of objects from a file and it seems to run much faster in C than in R. > But I don't want to release something that uses a non-public > function/interface. You say "much faster". Could this be related to what I recently observed: July 24, 2008 thread '[Rd] serialize() to via temporary file is heaps faster than doing it directly (on Windows)' [ https://stat.ethz.ch/pipermail/r-devel/2008-July/050256.html ]. My $0.02 /Henrik > > Thanks, > -roger > -- > Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ > > __ > 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] C versions of serialize/unserialize in packages
Hmm...I don't think so. The function I'm talking about loops over a file many times and does a lot of 'seeks'. I think just implementing the loop in C makes it faster. And besides, I see the speedup on Linux, which doesn't have the problem you mention. -roger On Thu, Jul 31, 2008 at 10:53 AM, Henrik Bengtsson <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, Jul 31, 2008 at 6:35 AM, Roger D. Peng <[EMAIL PROTECTED]> wrote: >> Are the functions 'R_Unserialize' and 'R_InitFileInPStream' allowed to >> be used in R packages? I guess I'm just not clear on the implications >> of this comment in 'Rinternals.h': >> >> /* The connection interface is not yet available to packages. To >> allow limited use of connection pointers this defines the opaque >> pointer type. */ >> >> I have a function in the 'filehash' package that unserializes a bunch >> of objects from a file and it seems to run much faster in C than in R. >> But I don't want to release something that uses a non-public >> function/interface. > > You say "much faster". Could this be related to what I recently observed: > > July 24, 2008 thread '[Rd] serialize() to via temporary file is heaps > faster than doing it directly (on Windows)' [ > https://stat.ethz.ch/pipermail/r-devel/2008-July/050256.html ]. > > My $0.02 > > /Henrik > > >> >> Thanks, >> -roger >> -- >> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ >> >> __ >> 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 > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C versions of serialize/unserialize in packages
On Thu, 31 Jul 2008, Roger D. Peng wrote: Are the functions 'R_Unserialize' and 'R_InitFileInPStream' allowed to be used in R packages? I guess I'm just not clear on the implications of this comment in 'Rinternals.h': /* The connection interface is not yet available to packages. To allow limited use of connection pointers this defines the opaque pointer type. */ It applies to R_InitFile(In|Out)PStream only, and is conditionalized by NEED_CONNECTION_PSTREAMS. You can't create a Rconnection pointer in your own C code in a public way. (The 'yet' has been there for nearly 7 years.) So what you are asking about is outside the conditional for that comment. I have a function in the 'filehash' package that unserializes a bunch of objects from a file and it seems to run much faster in C than in R. But I don't want to release something that uses a non-public function/interface. Thanks, -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 31 Jul 2008, at 10:29, Kjell Konis wrote:
Ernest,
Is it possible to provide a reproducible example of your crash?
Yes. R on macports depends on gcc43, which is causing the problems.
The best thing would be to make the port not depend on gcc43, and
instead depend on apple-supplied gcc (if this is possible).
Alternatively, the macports gcc43 build script should be fixed (e.g.
by looking at Apple's script, if available). Reproducible example:
Download and install gcc43 from Macports
cat - > foo.txt
Blah
Blah
^D
cat - > foo.cc
#include
#include
extern "C" {
void foo() {
char bar;
std::ifstream ifs("foo.txt");
std::ofstream ofs("foo2.txt");
ifs >> bar;
ofs << bar;
}
}
^D
cat - > foo.R
dyn.load("foo.so")
.C("foo")
^D
# Crash:
g++-mp-4.3 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R
# Don't crash:
g++-4.2 -shared -fPIC foo.cc -o foo.so
R --vanilla < foo.R
Kjell
On Jul 30, 2008, at 6:32 PM, Ernest Turro wrote:
On 30 Jul 2008, at 15:46, Simon Urbanek wrote:
On Jul 30, 2008, at 9:45 , Ernest Turro wrote:
Dear all,
R on Macports relies on GCC 4.3 to build packages. I find that
packages with shared objects that use C++ streams crash R if
they're compiled using Macports' gcc43, but work fine if compiled
in exactly the same way using Apple-supplied GCC 4.2. Has anyone
here had the same issue/know what is causing this problem?
Using compilers from MacPorts and similar suites (Darwin ports, Fink
etc.) is strongly discouraged (and outright not supported by the
CRAN binary) since they have been known to be badly broken in the
past and when whenever tested so far they were incomplete and
incompatible. You have to re-compile R yourself with those tools
(and you're entirely on your own) if you really want to use them.
CRAN binaries work only with Apple's gcc branches, if you want to
use anything else, you have to follow the unix R instructions and
compile everything from sources.
Dear Kjell,
As you can see above, your R port on Macports appears to be broken
and
has a reputation of having been broken for a while. I for one have
experienced odd problems as described above. To avoid further issues
with unsuspecting Macports users, perhaps it would be good to pull
the
port from the repository until a decent level of reliability can be
provided ?
Cheers,
Ernest
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C versions of serialize/unserialize in packages
On Thu, 31 Jul 2008, Prof Brian Ripley wrote: On Thu, 31 Jul 2008, Roger D. Peng wrote: Are the functions 'R_Unserialize' and 'R_InitFileInPStream' allowed to be used in R packages? I guess I'm just not clear on the implications of this comment in 'Rinternals.h': /* The connection interface is not yet available to packages. To allow limited use of connection pointers this defines the opaque pointer type. */ It applies to R_InitFile(In|Out)PStream only, and is conditionalized by NEED_CONNECTION_PSTREAMS. You can't create a Rconnection pointer in your own C code in a public way. (The 'yet' has been there for nearly 7 years.) Sorry the cut-and-paste went wrong: R_InitConn(In|Out)PStream only. So what you are asking about is outside the conditional for that comment. I have a function in the 'filehash' package that unserializes a bunch of objects from a file and it seems to run much faster in C than in R. But I don't want to release something that uses a non-public function/interface. Thanks, -roger -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AIX 5.3 --enable-R-shlib --with-x ---with-iconv make error with R-2.7.0 and R-2.7.1
Hi. Fán Lóng - san seems to have been able to build it in xlc,xlf. http://prs.ism.ac.jp/~nakama/AIX/ It is only gcc for AIX which is a buggy that I cannot build it well. --- Fán Lóng - san report - export OBJECT_MODE=64 export LIBICONV=/where/libiconv/installed ./configure \ CC="xlc_r -q64" \ CFLAGS="-O -qstrict" \ CXX="xlC_r -q64" \ CXXFLAGS="-O -qstrict" \ F77="xlf_r -q64" \ AR="ar -X64" \ CPPFLAGS="-I$LIBICONV/include -I/usr/lpp/X11/include/X11" \ LDFLAGS="-L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib" \ --enable-R-shlib \ --enable-BLAS-shlib \ --with-x --with-readline=no make make install LANG=C make check-all success!! -- EI-JI Nakama "\u4e2d\u9593\u6804\u6cbb" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
