Re: [Rd] Why is strptime always returning a vector of length 9 ?
l == laurent lgaut...@gmail.com on Sun, 09 Aug 2009 21:45:07 +0200 writes: l Thanks. It seems that the source of my confusion comes l from using first using str() (and then once on the wrong l track, it is easier to miss the information a man page l that also describes POSIXct that is itself a vector of l length equal to the number of entries it contains). l With the current example: str(xd) l POSIXlt[1:9], format: 2007-03-09 2007-05-31 l 2008-11-12 2008-11-12 ... l A quick inspection of the output does indicate a l something with nine elements, but the elements appear to l be 2007-03-09, 2007-05-31, etc... possibly creating l confusion. l To make it even more confusing I have: x[1] l [1] March 09, 2007 str(x[1]) l chr March 09, 2007 l For what it is worth, I think that the behavior of the l extract operator [ (defined as a S3 method l [.POSIXlt()) is inconsistent with the output of l length() (default method for lists). Yes, exactly; these two have beeb defined inconsistently, exactly in the respect you mention. Many months ago, when I came to the same conclusion, I vaguely remember that I had wanted / proposed to change this (namely, change [.POSIXlt, the length() method for POSIXlt) , but IIRC had been vetoed by others. ... another frustrating experience for me ... Martin Maechler, ETH Zurich l On Sun, 2009-08-09 at 11:45 -0500, Jeff Ryan wrote: The reason is in the ?strptime under value: 'strptime' turns character representations into an object of class 'POSIXlt'. The timezone is used to set the 'isdst' component and to set the 'tzone' attribute if 'tz != '. And POSIXlt is a list of length 9. HTH Jeff On Sun, Aug 9, 2009 at 10:35 AM, Gabor Grothendieckggrothendi...@gmail.com wrote: Try this to see its components: str(unclass(xd)) List of 9 $ sec : num [1:6] 0 0 0 0 0 0 $ min : int [1:6] 0 0 0 0 0 0 $ hour : int [1:6] 0 0 0 0 0 0 $ mday : int [1:6] 9 31 12 12 30 30 $ mon : int [1:6] 2 4 10 10 6 6 $ year : int [1:6] 107 107 108 108 109 109 $ wday : int [1:6] 5 4 3 3 4 4 $ yday : int [1:6] 67 150 316 316 210 210 $ isdst: int [1:6] 0 1 0 0 1 1 and read R News 4/1 for more. On Sun, Aug 9, 2009 at 10:20 AM, laurentlgaut...@gmail.com wrote: Dear List, I am having an issue with strptime (see below). I can reproduce it on R-2.8, R-2.9, and R-2.10-dev, I tempted to see either a bug or my misunderstanding (and then I just don't currently see where). # setup: x - c(March 09, 2007, May 31, 2007, November 12, 2008, November 12, 2008, July 30, 2009, July 30, 2009 ) # showing the problem length(x) 6 xd - strptime(x, format = %B %d, %Y) length(xd) 9 xd[1:9] [1] 2007-03-09 2007-05-31 2008-11-12 2008-11-12 2009-07-30 [6] 2009-07-30 NA NA NA length(strptime(rep(x, 2), format=%B %d, %Y)) [1] 9 strptime(rep(x, 2), format=%B %d, %Y)[1:12] [1] 2007-03-09 2007-05-31 2008-11-12 2008-11-12 2009-07-30 [6] 2009-07-30 2007-03-09 2007-05-31 2008-11-12 2008-11-12 [11] 2009-07-30 2009-07-30 Any pointer would be appreciated. L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why is strptime always returning a vector of length 9 ?
{Correcting thinko below .. }
MM == Martin Maechler maech...@stat.math.ethz.ch
on Mon, 10 Aug 2009 08:55:52 +0200 writes:
l == laurent lgaut...@gmail.com
on Sun, 09 Aug 2009 21:45:07 +0200 writes:
l Thanks. It seems that the source of my confusion comes
l from using first using str() (and then once on the wrong
l track, it is easier to miss the information a man page
l that also describes POSIXct that is itself a vector of
l length equal to the number of entries it contains).
l With the current example:
str(xd)
l POSIXlt[1:9], format: 2007-03-09 2007-05-31
l 2008-11-12 2008-11-12 ...
l A quick inspection of the output does indicate a
l something with nine elements, but the elements appear to
l be 2007-03-09, 2007-05-31, etc... possibly creating
l confusion.
l To make it even more confusing I have:
x[1]
l [1] March 09, 2007
str(x[1])
l chr March 09, 2007
l For what it is worth, I think that the behavior of the
l extract operator [ (defined as a S3 method
l [.POSIXlt()) is inconsistent with the output of
l length() (default method for lists).
MM Yes, exactly; these two have beeb defined inconsistently,
MM exactly in the respect you mention.
MM Many months ago, when I came to the same conclusion,
MM I vaguely remember that I had wanted / proposed to change this
MM (namely, change [.POSIXlt, the length() method for POSIXlt) ,
^^
length.POSIXlt was what I meant to write ...
MM but IIRC had been vetoed by others.
MM ... another frustrating experience for me ...
MM Martin Maechler, ETH Zurich
l On Sun, 2009-08-09 at 11:45 -0500, Jeff Ryan wrote:
The reason is in the ?strptime under value:
'strptime' turns character representations into an object of class
'POSIXlt'. The timezone is used to set the 'isdst' component
and to set the 'tzone' attribute if 'tz != '.
And POSIXlt is a list of length 9.
HTH
Jeff
On Sun, Aug 9, 2009 at 10:35 AM, Gabor
Grothendieckggrothendi...@gmail.com wrote:
Try this to see its components:
str(unclass(xd))
List of 9
$ sec : num [1:6] 0 0 0 0 0 0
$ min : int [1:6] 0 0 0 0 0 0
$ hour : int [1:6] 0 0 0 0 0 0
$ mday : int [1:6] 9 31 12 12 30 30
$ mon : int [1:6] 2 4 10 10 6 6
$ year : int [1:6] 107 107 108 108 109 109
$ wday : int [1:6] 5 4 3 3 4 4
$ yday : int [1:6] 67 150 316 316 210 210
$ isdst: int [1:6] 0 1 0 0 1 1
and read R News 4/1 for more.
On Sun, Aug 9, 2009 at 10:20 AM, laurentlgaut...@gmail.com wrote:
Dear List,
I am having an issue with strptime (see below).
I can reproduce it on R-2.8, R-2.9, and R-2.10-dev, I tempted to see
either a bug or my misunderstanding (and then I just don't currently
see
where).
# setup:
x - c(March 09, 2007, May 31, 2007, November 12, 2008,
November
12, 2008, July 30, 2009, July 30, 2009 )
# showing the problem
length(x)
6
xd - strptime(x, format = %B %d, %Y)
length(xd)
9
xd[1:9]
[1] 2007-03-09 2007-05-31 2008-11-12 2008-11-12 2009-07-30
[6] 2009-07-30 NA NA NA
length(strptime(rep(x, 2), format=%B %d, %Y))
[1] 9
strptime(rep(x, 2), format=%B %d, %Y)[1:12]
[1] 2007-03-09 2007-05-31 2008-11-12 2008-11-12 2009-07-30
[6] 2009-07-30 2007-03-09 2007-05-31 2008-11-12 2008-11-12
[11] 2009-07-30 2009-07-30
Any pointer would be appreciated.
L.
MM __
MM R-devel@r-project.org mailing list
MM 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] identical(0, -0)
On Sat, Aug 08, 2009 at 10:39:04AM -0400, Prof. John C Nash wrote:
I'll save space and not include previous messages.
My 2 cents: At the very least the documentation needs a fix. If it is
easy to do, then Ted Harding's suggestion of a switch (default OFF) to
check for sign difference would be sensible.
I would urge inclusion in the documentation of the +0, -0 example(s) if
there is NOT a way in R to distinguish these.
It is possible to distinguish 0 and -0 in R, since 1/0 == Inf and
1/(-0) == -Inf.
I do not know, whether there are also other such situations. In particular
(0)^(-1) == (-0)^(-1) # [1] TRUE
log(0) == log(-0) # [1] TRUE
There are occasions where
it is useful to be able to detect things like this (and NaN and Inf and
-Inf etc.). They are usually not of interest to users, but sometimes are
needed for developers to check edge effects. For those cases it may be
time to consider a package FPIEEE754 or some similar name to allow
testing and possibly setting of flags for some of the fancier features.
Likely used by just a few of us in extreme situations.
I think that distinguishing 0 and -0 may be useful even for nonexpert
users for debugging purposes. Mainly, because x == y does not imply
that x and y behave equally as demonstrated above or by
x - 0
y - - 0
x == y # [1] TRUE
1/x == 1/y # [1] FALSE
I would like to recall the suggestion
On Sat, Aug 08, 2009 at 03:04:07PM +0200, Martin Maechler wrote:
Maybe we should introduce a function that's basically
isTRUE(all.equal(..., tol=0)) {but faster}, or
do you want a 3rd argument to identical, say 'method'
with default c(oneNaN, use.==, strict)
oneNaN: my proposal of using memcmp() on doubles as its used for
other types already (and hence distinguishing +0 and -0;
otherwise keeping the feature that there's just one NaN
which differs from 'NA' (and there's just one 'NA').
use.==: the previous R behaviour, using '==' on doubles
(and the oneNaN behavior)
strict: be even stricter than oneNaN: Use memcmp()
unconditionally for doubles. This would be the fastest
version of all three.
In my opinion, for debugging purposes, the option
identical(x,y,method=strict),
which implies that x and y behave equally, could be useful, if it is available
in R base,
At the R interactive level, negative zero as the value of -0 could possibly
be avoided. However, negative zero may also occur in numerical calculations,
since it may be obtained as x * 0, where x is negative. So, i think, negative
zero cannot be eliminated from consideration as something too infrequent.
Petr.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Duplicated lines in configure
Hi There seems to be two functionally equivalent lines in the configure script https://svn.r-project.org/R/trunk/configure: ... --with-gnu-ld assume the C compiler uses GNU ld [default=no] --with-x use the X Window System --with-gnu-ld assume the C compiler uses GNU ld default=no ... These seems to come from the macro files m4/librool.m4 m4/gettext-lib.m4 I assume that to be consistent, one of these should be removed, and the other look something like --with-gnu-ld assume the C compiler uses GNU ld [no] Cheers --Rory [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
Petr Savicky wrote:
On Sat, Aug 08, 2009 at 10:39:04AM -0400, Prof. John C Nash wrote:
I'll save space and not include previous messages.
My 2 cents: At the very least the documentation needs a fix. If it is
easy to do, then Ted Harding's suggestion of a switch (default OFF) to
check for sign difference would be sensible.
I would urge inclusion in the documentation of the +0, -0 example(s) if
there is NOT a way in R to distinguish these.
It is possible to distinguish 0 and -0 in R, since 1/0 == Inf and
1/(-0) == -Inf.
I do not know, whether there are also other such situations. In particular
(0)^(-1) == (-0)^(-1) # [1] TRUE
log(0) == log(-0) # [1] TRUE
There are occasions where
it is useful to be able to detect things like this (and NaN and Inf and
-Inf etc.). They are usually not of interest to users, but sometimes are
needed for developers to check edge effects. For those cases it may be
time to consider a package FPIEEE754 or some similar name to allow
testing and possibly setting of flags for some of the fancier features.
Likely used by just a few of us in extreme situations.
I think that distinguishing 0 and -0 may be useful even for nonexpert
users for debugging purposes. Mainly, because x == y does not imply
that x and y behave equally as demonstrated above or by
x - 0
y - - 0
x == y # [1] TRUE
1/x == 1/y # [1] FALSE
I would like to recall the suggestion
On Sat, Aug 08, 2009 at 03:04:07PM +0200, Martin Maechler wrote:
Maybe we should introduce a function that's basically
isTRUE(all.equal(..., tol=0)) {but faster}, or
do you want a 3rd argument to identical, say 'method'
with default c(oneNaN, use.==, strict)
oneNaN: my proposal of using memcmp() on doubles as its used for
other types already (and hence distinguishing +0 and -0;
otherwise keeping the feature that there's just one NaN
which differs from 'NA' (and there's just one 'NA').
use.==: the previous R behaviour, using '==' on doubles
(and the oneNaN behavior)
strict: be even stricter than oneNaN: Use memcmp()
unconditionally for doubles. This would be the fastest
version of all three.
In my opinion, for debugging purposes, the option
identical(x,y,method=strict),
which implies that x and y behave equally, could be useful, if it is available
in R base,
At the R interactive level, negative zero as the value of -0 could possibly
be avoided. However, negative zero may also occur in numerical calculations,
since it may be obtained as x * 0, where x is negative. So, i think, negative
zero cannot be eliminated from consideration as something too infrequent.
I wouldn't mind a strict option. It would compare bit patterns, so
would distinguish +0 from -0, and different NaN values. But having the
value of identical(x-y, -(y-x)) depend on whether x and y are equal or
not would just lead to confusion.W
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] multicore mclapply hangs
When I execute mclapply it creates the needed processes, but these processes never begin computing anything, they just wait indefinitely. I recently upgraded to version 2.9.1, which might have caused the problem. -- Med venlig hilsen Rune Schjellerup Philosof Ph.d.-studerende, Statistik, IST, SDU Telefon: 6550 3607 E-mail: rphilo...@health.sdu.dk Adresse: J.B. Winsløwsvej 9, 5000 Odense C __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error Building R + X11 on SuSe 10
Hi all I am having problems building R + x11 support on the following system: # uname -a Linux 2.6.16.60-0.27-bigsmp #1 SMP Mon Jul 28 13:06:32 UTC 2008 i686 i686 i386 GNU/Linux # cat /etc/SuSE-release SUSE Linux Enterprise Server 10 (i586) VERSION = 10 PATCHLEVEL = 2 I am using the source download of R-2.9.1. My configure line is as follows: ./configure --with-x --with-gnu-ld gnu binutils versions: # gcc --version gcc (GCC) 4.1.2 20070115 (SUSE Linux) # ld --version GNU ld version 2.16.91.0.5 20051219 (SUSE Linux) Anyways, the problem seems to be (from config.log): configure:40036: checking for X configure:40279: result: libraries /usr/X11R6/lib, headers /usr/X11R6/include configure:40301: checking whether -R must be followed by a space configure:40335: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest. c -ldl -lm -R/usr/X11R6/lib 5 gcc: unrecognized option '-R/usr/X11R6/lib' configure:40341: $? = 0 configure: failed program was ... configure:40384: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest. c -ldl -lm -R /usr/X11R6/lib 5 gcc: unrecognized option '-R' /usr/X11R6/lib: file not recognized: Is a directory collect2: ld returned 1 exit status R is eventually built, but capabilities()[[X11]] returns FALSE. The issue may be that when I try (from the command line), this fails: # gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest.c -ldl -lm -R /usr/X11R6/lib/ But this works: # gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest.c -ldl -lm -Wl,-R /usr/X11R6/lib/ So essentially I guess I am asking in a long-winded way, how can I modify the above behaviour so it passes the correct information to the linker? (PS I have also tried --with-gnu-ld, and got the same result). Cheers -- Rory [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] multicore mclapply hangs
Hello Rune, please use the mailinglist 'R-sig-hpc' (https://stat.ethz.ch/mailman/listinfo/r-sig-hpc, do not forget to register!) for this topic. And please provide some more information: * in R: sessionInfo() * and your used operation system Best Markus Rune Schjellerup Philosof schrieb: When I execute mclapply it creates the needed processes, but these processes never begin computing anything, they just wait indefinitely. I recently upgraded to version 2.9.1, which might have caused the problem. -- Dipl.-Tech. Math. Markus Schmidberger Ludwig-Maximilians-Universität München IBE - Institut für medizinische Informationsverarbeitung, Biometrie und Epidemiologie Marchioninistr. 15, D-81377 Muenchen URL: http://www.ibe.med.uni-muenchen.de Mail: Markus.Schmidberger [at] ibe.med.uni-muenchen.de Tel: +49 (089) 7095 - 4497 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error Building R + X11 on SuSe 10S
Following on... Sorry folks, it looks like I have misdiagnosed the issue. When I connect to the server using an X client and start up the newly built R instance, I see capabilities() shows X11 support as expected. So this changes the character of my query somewhat: As I was hoping to run R in non-interactive mode (hence not using an X client in the first instance), is there any way to run R in headless mode, so that graphical output works, even in contexts where DISPLAY may not be set? (eg Java has an equivalent headless option that allows its graphical libraries to operate in such a situation, so I guess it must be possible, in theory at least). Best -- Rory [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error Building R + X11 on SuSe 10S
rory.wins...@gmail.com wrote: Following on... Sorry folks, it looks like I have misdiagnosed the issue. When I connect to the server using an X client and start up the newly built R instance, I see capabilities() shows X11 support as expected. So this changes the character of my query somewhat: As I was hoping to run R in non-interactive mode (hence not using an X client in the first instance), is there any way to run R in headless mode, so that graphical output works, even in contexts where DISPLAY may not be set? (eg Java has an equivalent headless option that allows its graphical libraries to operate in such a situation, so I guess it must be possible, in theory at least). I'm not an X11 user, but I believe the test systems do this using Xvfb, the virtual X server. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error Building R + X11 on SuSe 10S
Thanks Duncan. I have since found that building cairo and adding '--with-cairo' to the configure command solves this problem, and also gives (at least to my eyes) much nicer looking 2D png() plots. Cheers -- Rory On Aug 10, 2009 12:54pm, Duncan Murdoch murd...@stats.uwo.ca wrote: rory.wins...@gmail.com wrote: Following on... Sorry folks, it looks like I have misdiagnosed the issue. When I connect to the server using an X client and start up the newly built R instance, I see capabilities() shows X11 support as expected. So this changes the character of my query somewhat: As I was hoping to run R in non-interactive mode (hence not using an X client in the first instance), is there any way to run R in headless mode, so that graphical output works, even in contexts where DISPLAY may not be set? (eg Java has an equivalent headless option that allows its graphical libraries to operate in such a situation, so I guess it must be possible, in theory at least). I'm not an X11 user, but I believe the test systems do this using Xvfb, the virtual X server. Duncan Murdoch [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On Aug 10, 2009, at 5:47 , Duncan Murdoch wrote:
Petr Savicky wrote:
On Sat, Aug 08, 2009 at 10:39:04AM -0400, Prof. John C Nash wrote:
I'll save space and not include previous messages.
My 2 cents: At the very least the documentation needs a fix. If it
is easy to do, then Ted Harding's suggestion of a switch (default
OFF) to check for sign difference would be sensible.
I would urge inclusion in the documentation of the +0, -0
example(s) if there is NOT a way in R to distinguish these.
It is possible to distinguish 0 and -0 in R, since 1/0 == Inf and
1/(-0) == -Inf.
I do not know, whether there are also other such situations. In
particular
(0)^(-1) == (-0)^(-1) # [1] TRUE
log(0) == log(-0) # [1] TRUE
There are occasions where it is useful to be able to detect things
like this (and NaN and Inf and -Inf etc.). They are usually not of
interest to users, but sometimes are needed for developers to
check edge effects. For those cases it may be time to consider a
package FPIEEE754 or some similar name to allow testing and
possibly setting of flags for some of the fancier features. Likely
used by just a few of us in extreme situations.
I think that distinguishing 0 and -0 may be useful even for nonexpert
users for debugging purposes. Mainly, because x == y does not imply
that x and y behave equally as demonstrated above or by
x - 0
y - - 0
x == y # [1] TRUE
1/x == 1/y # [1] FALSE
I would like to recall the suggestion
On Sat, Aug 08, 2009 at 03:04:07PM +0200, Martin Maechler wrote:
Maybe we should introduce a function that's basically
isTRUE(all.equal(..., tol=0)) {but faster}, or
do you want a 3rd argument to identical, say 'method'
with default c(oneNaN, use.==, strict)
oneNaN: my proposal of using memcmp() on doubles as its
used for
other types already (and hence distinguishing +0 and -0;
otherwise keeping the feature that there's just one NaN
which differs from 'NA' (and there's just one 'NA').
use.==: the previous R behaviour, using '==' on doubles
(and the oneNaN behavior)
strict: be even stricter than oneNaN: Use memcmp()
unconditionally for doubles. This would be the fastest
version of all three.
In my opinion, for debugging purposes, the option
identical(x,y,method=strict),
which implies that x and y behave equally, could be useful, if it
is available
in R base,
At the R interactive level, negative zero as the value of -0 could
possibly
be avoided. However, negative zero may also occur in numerical
calculations,
since it may be obtained as x * 0, where x is negative. So, i
think, negative
zero cannot be eliminated from consideration as something too
infrequent.
I wouldn't mind a strict option. It would compare bit patterns,
so would distinguish +0 from -0, and different NaN values. But
having the value of identical(x-y, -(y-x)) depend on whether x and
y are equal or not would just lead to confusion.
... but so do other things routinely such as floating point
arithmetics so I don't think this is a strong argument here. IMHO
identical(0, -0) should return FALSE, because they are simply not the
same objects and that's what identical is supposed test for. If you
want to test equality of elements there are other means you should be
using that were mentioned in this thread.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On 8/10/2009 9:55 AM, Simon Urbanek wrote:
On Aug 10, 2009, at 5:47 , Duncan Murdoch wrote:
Petr Savicky wrote:
On Sat, Aug 08, 2009 at 10:39:04AM -0400, Prof. John C Nash wrote:
I'll save space and not include previous messages.
My 2 cents: At the very least the documentation needs a fix. If it
is easy to do, then Ted Harding's suggestion of a switch (default
OFF) to check for sign difference would be sensible.
I would urge inclusion in the documentation of the +0, -0
example(s) if there is NOT a way in R to distinguish these.
It is possible to distinguish 0 and -0 in R, since 1/0 == Inf and
1/(-0) == -Inf.
I do not know, whether there are also other such situations. In
particular
(0)^(-1) == (-0)^(-1) # [1] TRUE
log(0) == log(-0) # [1] TRUE
There are occasions where it is useful to be able to detect things
like this (and NaN and Inf and -Inf etc.). They are usually not of
interest to users, but sometimes are needed for developers to
check edge effects. For those cases it may be time to consider a
package FPIEEE754 or some similar name to allow testing and
possibly setting of flags for some of the fancier features. Likely
used by just a few of us in extreme situations.
I think that distinguishing 0 and -0 may be useful even for nonexpert
users for debugging purposes. Mainly, because x == y does not imply
that x and y behave equally as demonstrated above or by
x - 0
y - - 0
x == y # [1] TRUE
1/x == 1/y # [1] FALSE
I would like to recall the suggestion
On Sat, Aug 08, 2009 at 03:04:07PM +0200, Martin Maechler wrote:
Maybe we should introduce a function that's basically
isTRUE(all.equal(..., tol=0)) {but faster}, or
do you want a 3rd argument to identical, say 'method'
with default c(oneNaN, use.==, strict)
oneNaN: my proposal of using memcmp() on doubles as its
used for
other types already (and hence distinguishing +0 and -0;
otherwise keeping the feature that there's just one NaN
which differs from 'NA' (and there's just one 'NA').
use.==: the previous R behaviour, using '==' on doubles
(and the oneNaN behavior)
strict: be even stricter than oneNaN: Use memcmp()
unconditionally for doubles. This would be the fastest
version of all three.
In my opinion, for debugging purposes, the option
identical(x,y,method=strict),
which implies that x and y behave equally, could be useful, if it
is available
in R base,
At the R interactive level, negative zero as the value of -0 could
possibly
be avoided. However, negative zero may also occur in numerical
calculations,
since it may be obtained as x * 0, where x is negative. So, i
think, negative
zero cannot be eliminated from consideration as something too
infrequent.
I wouldn't mind a strict option. It would compare bit patterns,
so would distinguish +0 from -0, and different NaN values. But
having the value of identical(x-y, -(y-x)) depend on whether x and
y are equal or not would just lead to confusion.
... but so do other things routinely such as floating point
arithmetics so I don't think this is a strong argument here. IMHO
identical(0, -0) should return FALSE, because they are simply not the
same objects and that's what identical is supposed test for. If you
want to test equality of elements there are other means you should be
using that were mentioned in this thread.
+0 and -0 are exactly equal, which is what identical is documented to be
testing. They are not indistinguishable, and not identical in the
English meaning of the word, but they are identical in the sense of what
the identical() function is documented to test.
The cases where you want to distinguish between them are rare. They
should not be distinguished in the default identical() test, any more
than different values of NaN should be distinguished (and identical() is
explicitly documented *not* to distinguish those).
Of the 1600 uses of identical() in the R base plus recommended packages,
there are lots of cases where equality of elements is clearly the
intention. There are almost no uses of the all.equal(..., tol=0) idiom
in base R, and among the recommended packages, only Matrix uses it (but
uses identical() for values as well, I think.)
Distinguishing between different NaN values might be harmless, because
we probably only generate one. (I'm not sure about that, the literal
NaN might be different from sqrt(-1) or 0/0. But I'd guess only one
comes up in normal usage.) But we definitely generate both +0 and -0
all the time, and distinguishing between them would mean identical()
would be useless for value-based comparison. Do you want to evaluate
all 1600 uses in the base and recommended package, and who knows how
many on CRAN, to figure out which ones should be changed to
all.equal(..., tol=0)? I don't.
Duncan Murdoch
__
R-devel@r-project.org mailing list
[Rd] Rcpp and variable protection
Hi all, is there already a variable protection (as use else when linking to C/C++ e.g. PROTECT(a = AS_NUMERIC(a)); ) built in when using RcppExport from Rcpp? Many thanks, David [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
For people who want to play with these, here are some functions that let
you get or set the payload value in a NaN. NaN and NA, Inf and -Inf
are stored quite similarly; these functions don't distinguish which of
those you're working with. Regular finite values give NA for the
payload value, and elements of x are unchanged if you try to set their
payload to NA.
By the way, this also shows that R *can* distinguish different NaN
values, but you need some byte-level manipulations.
Duncan Murdoch
showBytes - function(x) {
bytes - rawConnection(raw(0), w)
on.exit(close(bytes))
writeBin(x, bytes)
rawConnectionValue(bytes)
}
NaNpayload - function(x) {
if (typeof(x) != double) stop(Can only handle doubles)
bytes - as.integer(showBytes(x))
base - 1 + (seq_along(x)-1)*8
S - bytes[base + 7] %/% 128
E - (bytes[base + 7] %% 128)*16 + bytes[base + 6] %/% 16
F - bytes[base + 6] %% 16
for (i in 5:0) {
F - F*256 + bytes[base + i]
}
nan - E == 2047 # Add F != 0 if you don't want to include
infinities
ifelse(nan, (1-2*S)*F/2^52, NA)
}
NaNpayload- - function(x, value) {
x - as.double(x)
payload - value
new - payload[!is.na(payload)]
if (any( new = -1 | new = 1 )) stop(The payload values must be
between -1 and 1)
payload - rep(payload, len=max(length(x), length(payload)))
x - rep(x, len=length(payload))
bytes - as.integer(showBytes(x))
base - 1 + (seq_along(x)-1)*8
base[is.na(payload)] - NA
F - trunc(abs(payload)*2^52)
for (i in 0:5) {
bytes[base + i] - F %% 256
F - F %/% 256
}
bytes[base + 6] - F + 0xF0
bytes[base + 7] - (payload 0)*128 + 0x7F
con - rawConnection(as.raw(bytes), r)
on.exit(close(con))
readBin(con, double, length(x))
}
Example:
x - c(NA, NaN, 0, 1, Inf)
NaNpayload(x)
[1] 0.5 -0.5 NA NA 0.0
NaNpayload(x) - -0.4
x
[1] NaN NaN NaN NaN NaN
y - x
NaNpayload(y) - 0.6
y
[1] NaN NaN NaN NaN NaN
NaNpayload(x)
[1] -0.4 -0.4 -0.4 -0.4 -0.4
NaNpayload(y)
[1] 0.6 0.6 0.6 0.6 0.6
identical(x, y)
[1] TRUE
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(0, -0)
On Mon, Aug 10, 2009 at 05:47:57AM -0400, Duncan Murdoch wrote: I wouldn't mind a strict option. It would compare bit patterns, so would distinguish +0 from -0, and different NaN values. I think that a logical option strict in the above meaning could be useful for debugging. The default may be FALSE. On Mon, Aug 10, 2009 at 10:20:39AM -0400, Duncan Murdoch wrote: +0 and -0 are exactly equal, which is what identical is documented to be testing. They are not indistinguishable, and not identical in the English meaning of the word, but they are identical in the sense of what the identical() function is documented to test. The cases where you want to distinguish between them are rare. They should not be distinguished in the default identical() test, any more than different values of NaN should be distinguished (and identical() is explicitly documented *not* to distinguish those). [...] The question, whether 0 and -0 are equal or not, is not clear, since they have different reciprocals. However, i agree that distinguishing the signs of zero is rarely useful. From this point of view, the default FALSE seems to be acceptable. For completeness, let me also add an argument that it would not be too harmful, if the default is TRUE. I think that it is quite rare to have two larger numerical structures, which match up to the last bits in all numbers, but have a different sign of some zero. Matching all bits almost requires that the two structures are obtained using the same expressions for all components. Then, also the signs of zeros will match. However, i may be wrong. Petr. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)
A wild guess, based on some recent non-deterministic behavior in lme4: could this be driven by a bug in optimized linear algebra libraries (BLAS/LAPACK)? (Unfortunately, I'm not clear on how to check the versions of BLAS/LAPACK being used and whether they are subject to bugs, but perhaps someone else can comment ...) Ben Bolker Adam D. I. Kramer-2 wrote: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1660387551-150661043-1249684349=:2997 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Jeff, =09As mentioned in my message, I *did* replicate on another platform.=20 One platform was running linux in a VM, the other running MacOSX, on two different physical machines. The problem did not replicate on a PowerPC box, so if it is a bug with intel chips, I think it's also appropriate to report here given that the problem seems to cross the OS boundary. I do no= t have access to a Windows machine. =09Also, I have spent a decent amount of time running memory testers on the first machine's memory, to ensure that physical memory is not a problem...the classic memcheck program finds no trouble. =09The CSV and .ram files both came through as base-64-encoded attachments, which you actually quoted back to me in your response, below...but in case your mail client can't read those and/or you are interested in this bug, I have pasted them at the end of this message (sinc= e they're quite small). =09And thanks for the shout-out for bacon. I bought this domain name in undergrad many years ago, and I must say, I've never regretted it! --Adam On Fri, 7 Aug 2009, Jeff Ryan wrote: Adam, It seems that your attachment didn't make it through. That aside, my experience with strange errors like those (random type not implemented ones) has been that you may be looking at a memory problem on you machine. Given that you can't replicate on another platform (and the .csv file didn't come through), I would think it wise to start there. My 2c. And I love bacon too :) Jeff On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote: =A0This message is in MIME format. =A0The first part should be readable = text, =A0while the remaining parts are likely unreadable without MIME-aware to= ols. --1660387551-1458482416-1249639718=3D:2997 Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII; FORMAT=3Dflowed Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org Hello, =A0 =A0 =A0 =A0There appears to be a bug in the nlm function, which I di= scovered when trying to run an SEM. =A0The SEM is not bizarre; the covariance mat= rix is solve-able and the eigenvalues are greater than zero, and I do not belie= ve the sem package per se to be the problem (as nlm keeps being the part = that fails, though I can't replicate this with other nlm tasks). =A0I apologi= ze if I have put too many much information in this message; I'm not a programm= er by trade so I don't really know what's going on here, which hampers my ability to write consise bug reports. Here is the code I use: library(sem) ice.S - read.csv(iceS.csv) # attached rownames(ice.S) - ice.S[,1] ice.S[,1] - NULL ice.S - as.matrix(ice.S) ice.ram - specify.model(ice.ram) # attached ice.N - 342 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N) ...at this point, any number of problems could occur. I have seen the following. 1) Simple lack of convergence. (might be my model's fault.) 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, sta= rt, : =A0 type 31 is unimplemented in 'type2char' 3) =A0*** caught segfault *** address 0xc019c87b, cause 'memory not mapped' Traceback: =A01: nlm(if (analytic.gradient) objective.2 else objective.1, start, hessian =3D TRUE, iterlim =3D maxiter, print.level =3D if (debug) 2 else= 0, typsize =3D typsize, ...) =A02: sem.default(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, v= ar.names =3D vars, =A0 =A0 fixed.x =3D fixed.x, debug =3D debug, ...) =A03: sem(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, var.names= =3D vars, fixed.x =3D fixed.x, debug =3D debug, ...) =A04: sem.mod(ram =3D ice.ram, S =3D ice.S, N =3D ice.N) =A05: sem(ram =3D ice.ram, S =3D ice.S, N =3D ice.N) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: 1 aborting ... Segmentation fault swiss:data$ (no core was dumped). Trying with debug mode provides other interesting errors: ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N, debug=3DTRUE) ...gets up to some iteration (not always 15), and then R dies ungraceful= ly, and exits to the shell: iteration =3D 15 Step: =A0[1] =A01.253132e-02 =A01.183343e-02 -7.651342e-03 -2.490800e-03 =A02.=
Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)
William Dunlap wrote:
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Ben Bolker
Sent: Monday, August 10, 2009 12:52 PM
To: r-devel@r-project.org
Subject: Re: [Rd] Bug in nlm, found using sem; failure in
several flavors (PR#13883)
A wild guess, based on some recent non-deterministic behavior in
lme4: could this be driven by a bug in optimized linear
algebra libraries
(BLAS/LAPACK)? (Unfortunately, I'm not clear on how to check
the versions
of BLAS/LAPACK being used and whether they are subject to bugs,
but perhaps someone else can comment ...)
Ben Bolker
Running his example under valgrind (a memory misuse checker on Linux)
does show it using memory it should not be using in the optimization C
code
around where it is copying the gradient vector. The
==10916== Invalid read of size 1
==10916==at 0x400686D: memcpy (mc_replace_strmem.c:406)
==10916==by 0x8072BC1: FT_store (optimize.c:319)
==10916==by 0x8072F92: fcn (optimize.c:408)
...
Mmmm... This comes from this code inside fcn()
if (state-have_gradient) {
g = REAL(coerceVector(getAttrib(s, install(gradient)),
REALSXP));
if (state-have_hessian) {
h = REAL(coerceVector(getAttrib(s, install(hessian)),
REALSXP));
}
}
FT_store(n, *f, x, g, h, state);
I suppose that if the function being optimized returns a value that has
a gradient attribute, then that is being used. It is coerced to
double; but otherwise, no questions asked.
I wonder if it would not be a good idea to at least check that
getAttrib() returns something of the right length.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] model.matrix evaluation challenges
how about... nrow(with(cc, model.matrix(params, data=environment( cheers -Felix 2009/8/10 Ben Bolker bol...@ufl.edu: I am having difficulty with evaluation/environment construction for a formula to be evaluated by model.matrix(). Basically, I want to construct a model matrix that first looks in newdata for the values of the model parameters, then in obj...@data. Here's what I've tried: 1. model.matrix(~f,data=c(newdata,obj...@data)) -- fails because something (terms()?) within model.matrix() tries to coerce data to a data frame -- but newdata and obj...@data have different numbers of rows. 2. with(c(newdata,obj...@data),model.matrix(~f)) works -- BUT not when ~f is assigned to another object (as it will be when it is being dug out of a previously fit model). 3. If f exists as a column within newdata and/or obj...@data, but the formula is assigned to another object (see below), then with(c(newdata,obj...@data),model.matrix(z)) fails -- because model.matrix() is explicitly evaluating the variables in the formula in the environment of z (i.e., ignoring the first argument of with ...) Any advice on how to solve this without making a bigger mess? sincerely Ben Bolker ## set up a data frame for prediction set.seed(1001) f = factor(rep(letters[1:4],each=20)) x = runif(80) u = rnorm(4) y = rnorm(80,mean=2+x*(3+u[f]),sd=0.1) dat = data.frame(f,x,y) ## fit a model ... could easily do by lm() but want to ## demonstrate the problem library(bbmle) m1 = mle2(y~dnorm(a+b*x,sd=exp(logs)),parameters=list(b~f),data=dat, start=list(a=0,b=2,logs=-3)) ## data frame for prediction pp0 = expand.grid(x=seq(0,1,length=11), f=levels(dat$f)) ## combine frame and model data: have to keep the model data ## around, because it contain other information needed for ## prediction. cc = c(pp0,m...@data) try(mm - model.matrix(~f,cc)) ## fails -- different number of rows ## (at some point R tries to coerce cc to a data frame) nrow(with(cc,model.matrix(~f))) ## works ... but ... ## here's what happens within predict.mle2() ## extract information about parameter models params - eval(m...@call$parameters) params - params[[1]] params[[2]] - NULL nrow(with(cc,model.matrix(params))) rm(f) ## object f not found -- because model.matrix ## evaluates in the parent environment of params ... try(nrow(with(cc,model.matrix(params -- Ben Bolker Associate professor, Biology Dep't, Univ. of Florida bol...@ufl.edu / www.zoology.ufl.edu/bolker GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 1670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
