[Rd] parsing Rd files and \deqn{}
Hi
[R-2.9.0]
I am having difficulty including a LaTeX formula in an Rd
file.
The example given in section 2.7 in 'Parsing Rd files' is:
\deqn{ f(x) = \left\{
\begin{array}{ll}
0 & x<0 \\
1 & x\ge 0
\end{array}
\right. }{non latex}
For me, this gives:
\deqn{ f(x) = \left\{
\begin{array}{ll}
0 \& x<0 \bsl{}
1 \& x\ge 0
\end{array}
\right. }{}
in the tex file, which is not desired because the ampersand
is escaped; the '&' symbol appears in the dvi file, and I
want an ampersand to indicate alignment.
Also, the '\\' appears as \bsl{}, which is undesired; the
resulting dvi file (made by R CMD Rd2dvi) looks wrong.
How do I write the Rd file so as to produce non-escaped
ampersands?
--
Robin K. S. Hankin
Uncertainty Analyst
University of Cambridge
19 Silver Street
Cambridge CB3 9EP
01223-764877
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behavior of rpart 3.1-43, loss matrix
Hi,
I just noticed that rpart behaves unexpectecly, when performing
classification learning and specifying a loss matrix.
if the response variable y is a factor and if not all levels of the
factor occur in the observations, rpart exits with an error:
> df=data.frame(attr=1:5,class=factor(c(2,3,1,5,3),levels=1:6))
> rpart(class~attr,df,parms=list(loss=matrix(0,6,6)))
Error in (get(paste("rpart", method, sep = ".")))(Y, offset, parms, wt)
: Wrong length for loss matrix
note that while the levels of the factor range from 1:6, for the
concrete obseration data, only levels 1, 2, 3, 5 do occur.
the error is caused by the code of rpart.class:
fy <- as.factor(y)
y <- as.integer(fy)
numclass <- max(y[!is.na(y)])
...
temp2 <- parms$loss
if (length(temp2) != numclass^2)
stop("Wrong length for loss matrix")
for the example, numclass is set to 5 instead of 6.
while for that small example, it may be discussable whether or not
numclass should be 6, consider a set of data for that the response
variable has a certain range. Then, it may be the case that for some
data, not all levels of the response variable do occur. at the same
time, it is desirable to use the same loss matrix when training a
deicision tree from the data.
having said that, i am very happy with the rpart package and with its
high configurability.
best regards
lars
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
> William Dunlap
> on Thu, 30 Apr 2009 10:51:43 -0700 writes:
> On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in
> particular)
> with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when
is this really gcc 3.4.5 (which is quite old) ?
Without being an expert, I'd tend to claim this to be a
compiler (optimization) bug but most probably the ANSI /
ISO C (and libc ?) standards would not define the exact
behavior of arithmetic with NaNs.
> adding NA and NaN:
>> NA_real_ + NaN
> [1] NaN
>> NaN + NA_real_
> [1] NA
> If I compile src/main/arithmetic.c without optimization (just -g)
> then both of those return NA.
> On Windows, using a precompiled R 2.8.1 from CRAN I get
> NA for both answers.
> On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit
> patterns for NA_real_ and as.numeric(NA) are different:
>> my_numeric_NA <- as.numeric(NA)
>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff0
> 010
> On Linux, after compiling with -g the bit patterns for NA_real_
> and as.numeric(NA) are identical.
>> my_numeric_NA <- as.numeric(NA)
>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
> On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those
> gave the 7ff8 version.
> Is this confounding of NA and NaN of concern or does R not promise to
> keep NA and NaN distinct?
Hmm, I'd say it *is* of some concern that "+" is not commutative
in the narrow sense, even if I don't know what exactly "R promises".
> I haven't followed all the macros, but it looks like arithmetic.c just
> does
> result[i]=x[i]+y[i]
> and lets the compiler/floating point unit decide what to do when x[i]
> and y[i]
> are different NaN values (NA is a NaN value). I haven't looked at the C
> code
> for the initialization of NA_real_. Adding explicit tests for NA-ness
> in the
> binary operators (as S+ does) adds a fairly significant cost.
Yes, I would be quite reluctant to add such
tests, because such costs are to be expected.
Maybe we ("R" :-) should explicitly state that operations mixing
NA & NaN give a result which is NA in the sense of fulfilling is.na(.)
but *not* promise anything further.
Martin Maechler, ETH Zurich
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
> "MM" == Martin Maechler
> on Fri, 1 May 2009 14:14:58 +0200 writes:
> William Dunlap
> on Thu, 30 Apr 2009 10:51:43 -0700 writes:
>> On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in
>> particular)
>> with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when
MM> is this really gcc 3.4.5 (which is quite old) ?
MM> Without being an expert, I'd tend to claim this to be a
MM> compiler (optimization) bug but most probably the ANSI /
MM> ISO C (and libc ?) standards would not define the exact
MM> behavior of arithmetic with NaNs.
>> adding NA and NaN:
>>> NA_real_ + NaN
>> [1] NaN
>>> NaN + NA_real_
>> [1] NA
>> If I compile src/main/arithmetic.c without optimization (just -g)
>> then both of those return NA.
>> On Windows, using a precompiled R 2.8.1 from CRAN I get
>> NA for both answers.
>> On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit
>> patterns for NA_real_ and as.numeric(NA) are different:
>>> my_numeric_NA <- as.numeric(NA)
>>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
>> 000 07a2 7ff8
>> 010
>>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
>> 000 07a2 7ff0
>> 010
>> On Linux, after compiling with -g the bit patterns for NA_real_
>> and as.numeric(NA) are identical.
>>> my_numeric_NA <- as.numeric(NA)
>>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
>> 000 07a2 7ff8
>> 010
>>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
>> 000 07a2 7ff8
>> 010
>> On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those
>> gave the 7ff8 version.
I've run a couple of
echo 'c(NA+NaN, NaN+NA)' | R --slave --vanilla
on 3 different platforms, all Linux, and many installed versions
of R -- all of which compiled with defaults, i.e. '-O2',
and depending on its release date, compiled with
different versions of gcc {I can still check these
because I run R from the installation directory, with
all configure results ..}
on a given platform, and have observed the following:
The result is always "NA NA" (as desired!) iff the platform is 32-bit,
whereas it is"NaN NA" for the 64-bit platform and older
versions of R (R <= 2.3.1)
and "NA NaN" for versions of R (>= 2.4.1)
{{but note: the versions of R are confounded with the versions of gcc ...}}
Further, as the 64-bit platform can also use the 32-bit versions of R,
I've tested a few and found that indeed, the 32-bit version of R
would return "NA NA" also on the 64-bit platform.
Martin
>> Is this confounding of NA and NaN of concern or does R not promise to
>> keep NA and NaN distinct?
MM> Hmm, I'd say it *is* of some concern that "+" is not commutative
MM> in the narrow sense, even if I don't know what exactly "R promises".
>> I haven't followed all the macros, but it looks like arithmetic.c just
>> does
>> result[i]=x[i]+y[i]
>> and lets the compiler/floating point unit decide what to do when x[i]
>> and y[i]
>> are different NaN values (NA is a NaN value). I haven't looked at the C
>> code
>> for the initialization of NA_real_. Adding explicit tests for NA-ness
>> in the
>> binary operators (as S+ does) adds a fairly significant cost.
MM> Yes, I would be quite reluctant to add such
MM> tests, because such costs are to be expected.
MM> Maybe we ("R" :-) should explicitly state that operations mixing
MM> NA & NaN give a result which is NA in the sense of fulfilling is.na(.)
MM> but *not* promise anything further.
MM> Martin Maechler, ETH Zurich
>> Bill Dunlap
>> TIBCO Software Inc - Spotfire Division
>> wdunlap tibco.com
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] NA_real_ NaN -> NA or NaN, should we care?
On 5/1/2009 8:14 AM, Martin Maechler wrote:
William Dunlap
on Thu, 30 Apr 2009 10:51:43 -0700 writes:
> On Linux when I compile R 2.10.0(devel) (src/main/arithmetic.c in
> particular)
> with gcc 3.4.5 using the flags -g -O2 I get noncommutative behavior when
is this really gcc 3.4.5 (which is quite old) ?
Without being an expert, I'd tend to claim this to be a
compiler (optimization) bug but most probably the ANSI /
ISO C (and libc ?) standards would not define the exact
behavior of arithmetic with NaNs.
Here are a few bits of information, not particularly well organized:
I don't know if the IEEE 754 (or the ISO equivalent) specifies the
behaviour, but the hardware handling of NaNs is inconsistent on Intel
chips. If two NaNs are involved in an operation, it returns the one
with the larger significand when operations are done in the FPU, it
returns the first one when they are done in the SSE.
Our NA has a bigger significand than the default NaN, but there are NaNs
that are bigger. (We're unlikely to see those in the results of
arithmetic under our control, but there's nothing to stop external code
from returning one, or getting one via readBin from a file.)
The type can be either quiet or signalling; our NA is a signalling NaN,
and the one Bill was getting from the as.numeric conversion is a quiet
NaN. However, our IsNA test doesn't look at the bits determining that
status, it only looks at the 07a2 part, so both are displayed as
NA. I haven't traced the coercion code to know why they aren't
identical, but I think it doesn't matter: the FPU and SSE methods are
inconsistent for most pairs of operands.
All of which leads me to conclude that we should either say we don't
guarantee what happens when you mix NA with NaN, or we should add an
explicit test to every operation. I'd prefer the "no guarantees" solution.
Duncan Murdoch
> adding NA and NaN:
>> NA_real_ + NaN
> [1] NaN
>> NaN + NA_real_
> [1] NA
> If I compile src/main/arithmetic.c without optimization (just -g)
> then both of those return NA.
> On Windows, using a precompiled R 2.8.1 from CRAN I get
> NA for both answers.
> On Linux, after compiling src/main/arithmetic.c with -g -O2 the bit
> patterns for NA_real_ and as.numeric(NA) are different:
>> my_numeric_NA <- as.numeric(NA)
>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff0
> 010
> On Linux, after compiling with -g the bit patterns for NA_real_
> and as.numeric(NA) are identical.
>> my_numeric_NA <- as.numeric(NA)
>> writeBin(my_numeric_NA, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
>> writeBin(NA_real_, ptmp<-pipe("od -x", open="wb"));close(ptmp)
> 000 07a2 7ff8
> 010
> On Windows, using precompiled R 2.8.1 and cygwin/bin/od, both of those
> gave the 7ff8 version.
> Is this confounding of NA and NaN of concern or does R not promise to
> keep NA and NaN distinct?
Hmm, I'd say it *is* of some concern that "+" is not commutative
in the narrow sense, even if I don't know what exactly "R promises".
> I haven't followed all the macros, but it looks like arithmetic.c just
> does
> result[i]=x[i]+y[i]
> and lets the compiler/floating point unit decide what to do when x[i]
> and y[i]
> are different NaN values (NA is a NaN value). I haven't looked at the C
> code
> for the initialization of NA_real_. Adding explicit tests for NA-ness
> in the
> binary operators (as S+ does) adds a fairly significant cost.
Yes, I would be quite reluctant to add such
tests, because such costs are to be expected.
Maybe we ("R" :-) should explicitly state that operations mixing
NA & NaN give a result which is NA in the sense of fulfilling is.na(.)
but *not* promise anything further.
Martin Maechler, ETH Zurich
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
__
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] NA_real_ NaN -> NA or NaN, should we care?
> From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> Sent: Friday, May 01, 2009 5:15 AM
> To: William Dunlap
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
>
> > William Dunlap
> > on Thu, 30 Apr 2009 10:51:43 -0700 writes:
>
> > On Linux when I compile R 2.10.0(devel)
> (src/main/arithmetic.c in
> > particular)
> > with gcc 3.4.5 using the flags -g -O2 I get
> noncommutative behavior when
>
> is this really gcc 3.4.5 (which is quite old) ?
Yes, it was 3.4.5, but here is a self-contained example of the same
issue using gcc 4.1.3 on an Ubuntu Linux machine:
% gcc -O2 t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
% gcc t.c -o a.out ; ./a.out
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: 7ff807a2
% gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
% cat t.c
#include
#include
#include
int main(int argc, char *argv[])
{
int64_t NA_int64 = 0x7ff007a2LL ;
int64_t NaN_int64 = 0xfff8LL ;
int64_t sum_int64 ;
double NA_double, NaN_double, sum_double ;
memcpy((void*)&NA_double, (void*)&NA_int64, 8) ;
memcpy((void*)&NaN_double, (void*)&NaN_int64, 8) ;
NaN_double = 1/0.0 - 1/0.0 ;
printf("NA : %Lx\n", *(int64_t*)&NA_double);
printf("NaN: %Lx\n", *(int64_t*)&NaN_double);
sum_double = NA_double + NaN_double ;
memcpy((void*)&sum_int64, (void*)&sum_double, 8) ;
printf("NA+NaN: %Lx\n", sum_int64) ;
sum_double = NaN_double + NA_double ;
memcpy((void*)&sum_int64, (void*)&sum_double, 8) ;
printf("NaN+NA: %Lx\n", sum_int64);
return 0 ;
}
When I add -Wall to the -O2 then it gives me some warnings about the
*(int64_t)&doubleVal in the printf statements for the inputs, but I used
memcpy() to avoid the warnings when printing the outputs.
% gcc -Wall -O2 t.c -o a.out ; ./a.out
t.c: In function âmainâ:
t.c:17: warning: dereferencing type-punned pointer will break strict-aliasing
rules
t.c:18: warning: dereferencing type-punned pointer will break strict-aliasing
rules
NA : 7ff007a2
NaN: fff8
NA+NaN: 7ff807a2
NaN+NA: fff8
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] crash after using graphics in Rcmdr (PR#13679)
John, To the best of my knowledge this problem in R.app has been around at least since the R-2.8 days, but likely much longer. I never use R from a Terminal, so don't know if it occurs or not outside R.app. It's not related to Rcmdr and you're observation is indeed one of the better ways to kind of reproduce the issue. Not sure if it always does though. If you have a 'hard' way of crashing R.app, please let me know the sequence. In cases when no output is written to the console of R.app I tend to make sure I enter an empty line before closing the graphics window. This issue and sometimes very long sequences of plots (never have been able to make that reproducible, sometimes the crash happens up to a minute after R finishes a series of plots and I'm working in an external editor like TextMate) are hard to pin down. Regards, Rob Note: Hope you don't mind I've removed the R-bugs & R-devel Cc's. On Apr 30, 2009, at 6:29 AM, John Fox wrote: > Dear Neil, > > I had R 2.8.0 installed on my Mac Book, also with OS X 10.5.6, and was > unable to duplicate this problem. I then installed R 2.9.0 and > observed the > same problem that you did. In both cases, I used the latest version > of the > Rcmdr package, 1.4-10. > > I also observed the following: (1) The problem occurred only if I > closed the > Quartz graphics device after the first graph was plotted; if I plotted > another graph and then closed the device, the problem did not occur. > (2) The > problem did not occur if I ran R from a terminal with an X11 > graphics device > rather than using R.app. > > I'm afraid that there's not much more that I can do at this point, > since my > familiarity with Macs is minimal. I'm copying this message to Rob > Goedman, > who has proven helpful in the past. Of course, if there's something > in the > Rcmdr that's causing the problem and I can fix it, I will. > > Regards, > John > > >> -Original Message- >> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org >> ] > On >> Behalf Of nhepb...@ualberta.ca >> Sent: April-28-09 1:25 PM >> To: r-de...@stat.math.ethz.ch >> Cc: r-b...@r-project.org >> Subject: [Rd] crash after using graphics in Rcmdr (PR#13679) >> >> Full_Name: Neil Hepburn >> Version: 2.81 and 2.90 >> OS: OS-X 10.5.6 >> Submission from: (NULL) (142.244.28.93) >> >> >> When I create graphs using Rcmdr and then close the quartz display, R > blows >> up >> and tells me of a segmentation fault. It then gives me >> *** caught segfault *** >> address 0xc023, cause 'memory not mapped' >> >> 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: >> >> This only happens if I create the graphics from within Rcmdr. If I >> create > the >> graphics manually, there is no problem. This occurs on my laptop >> with R > 2.8.1 >> (I >> uninstalled 2.9 and reinstall 2.8.1 to see if the problem existed >> there) > and >> also on my iMac with R2.9. >> >> __ >> 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
Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
The optimizer in gcc 4.2 (but not 4.1) on Linux seems to get this
issue "right" on one of my test machines (a 32-bit Ubuntu box).
4.1 fails on a 64-bit Linux but I don't have a newer gcc on any
64-bit Linux machine I can find.
A cleaner version of the test is:
% cat t.c
#include
#include
#include
void print_double(char *text, double x_double)
{
int64_t x_int64 ;
memcpy((void*)&x_int64, (void*)&x_double, 8) ;
printf("%s: %Lx (%g)\n", text, x_int64, x_double) ;
}
int main(int argc, char *argv[])
{
int64_t NA_int64 = 0x7ff007a2LL ;
int64_t NaN_int64 = 0xfff8LL ;
double NA_double, NaN_double, sum_double ;
memcpy((void*)&NA_double, (void*)&NA_int64, 8) ;
memcpy((void*)&NaN_double, (void*)&NaN_int64, 8) ;
print_double(" NA", NA_double);
print_double("NaN", NaN_double);
sum_double = NA_double + NaN_double ;
print_double("NA+NaN", sum_double) ;
sum_double = NaN_double + NA_double ;
print_double("NaN+NA", sum_double);
return 0 ;
}
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of William Dunlap
> Sent: Friday, May 01, 2009 7:50 AM
> To: Martin Maechler
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
>
> > From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
> > Sent: Friday, May 01, 2009 5:15 AM
> > To: William Dunlap
> > Cc: r-devel@r-project.org
> > Subject: Re: [Rd] NA_real_ NaN -> NA or NaN, should we care?
> >
> > > William Dunlap
> > > on Thu, 30 Apr 2009 10:51:43 -0700 writes:
> >
> > > On Linux when I compile R 2.10.0(devel)
> > (src/main/arithmetic.c in
> > > particular)
> > > with gcc 3.4.5 using the flags -g -O2 I get
> > noncommutative behavior when
> >
> > is this really gcc 3.4.5 (which is quite old) ?
>
> Yes, it was 3.4.5, but here is a self-contained example of the same
> issue using gcc 4.1.3 on an Ubuntu Linux machine:
>
> % gcc -O2 t.c -o a.out ; ./a.out
> NA : 7ff007a2
> NaN: fff8
> NA+NaN: 7ff807a2
> NaN+NA: fff8
> % gcc t.c -o a.out ; ./a.out
> NA : 7ff007a2
> NaN: fff8
> NA+NaN: 7ff807a2
> NaN+NA: 7ff807a2
> % gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang
> --prefix=/usr --enable-shared --with-system-zlib
> --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.1.3
> --program-suffix=-4.1 --enable-__cxa_atexit
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --enable-checking=release i486-linux-gnu
> Thread model: posix
> gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> % cat t.c
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> int64_t NA_int64 = 0x7ff007a2LL ;
> int64_t NaN_int64 = 0xfff8LL ;
> int64_t sum_int64 ;
> double NA_double, NaN_double, sum_double ;
>
> memcpy((void*)&NA_double, (void*)&NA_int64, 8) ;
> memcpy((void*)&NaN_double, (void*)&NaN_int64, 8) ;
>
> NaN_double = 1/0.0 - 1/0.0 ;
>
> printf("NA : %Lx\n", *(int64_t*)&NA_double);
> printf("NaN: %Lx\n", *(int64_t*)&NaN_double);
> sum_double = NA_double + NaN_double ;
> memcpy((void*)&sum_int64, (void*)&sum_double, 8) ;
> printf("NA+NaN: %Lx\n", sum_int64) ;
> sum_double = NaN_double + NA_double ;
> memcpy((void*)&sum_int64, (void*)&sum_double, 8) ;
> printf("NaN+NA: %Lx\n", sum_int64);
> return 0 ;
> }
>
> When I add -Wall to the -O2 then it gives me some warnings about the
> *(int64_t)&doubleVal in the printf statements for the inputs,
> but I used
> memcpy() to avoid the warnings when printing the outputs.
>
> % gcc -Wall -O2 t.c -o a.out ; ./a.out
> t.c: In function âmainâ:
> t.c:17: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> t.c:18: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> NA : 7ff007a2
> NaN: fff8
> NA+NaN: 7ff807a2
> NaN+NA: fff8
>
> Bill Dunlap
> TIBCO Software Inc - Spotfire Division
> wdunlap tibco.com
>
> __
> 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
[Rd] a statement about package licenses
We are writing on behalf of the R Foundation, to clarify our position on the licenses under which developers may distribute R packages. Readers should also see FAQ 2.11: this message is not legal advice, which we never offer. Readers should also be aware that besides the R Foundation, R has many other copyright holders, listed in the copyright notices in the source. Each of those copyright holders may have a different opinion on the issues discussed here. We welcome packages that extend the capabilities of R, and believe that their value to the community is increased if they can be offered with open-source licenses. At the same time, we have no desire to discourage other license forms that developers feel are required. Of course, such licenses as well as the contents of the package and the way in which it is distributed must respect the rights of the copyright holders and the terms of the R license. When we think that a package is in violation of these rights, we contact the author directly, and so far package authors have always agreed to comply with our license (or convinced us that they are already in compliance). We have no desire to be involved in legal actions---our interest is in providing good software. However, everyone should understand that there are conceivable circumstances in which we would be obliged to take action. Our experience to date and the assurances of some fine commercial developers make us optimistic that these circumstances will not arise. The R Foundation __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] nlminb - Port library codes
Having looked at documentation and codes, I'm still looking to find out who did the installation of the Port libraries. As I work on optimization code improvements, there are often choices of settings (tolerances etc.), and I'd prefer to learn if there are particular reasons for choices before diving in and making any adjustments. It is also worth giving credit where it is due. Given the complexity of the Port code structure, adapting them to R must have been a lot of work. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] crash after using graphics in Rcmdr (PR#13679)
This happens to me every time I try a plot command from TextWrangler with the following applescript tell application "TextWrangler" set the_selection to (selection of front window as string) if (the_selection) is "" then set the_selection to line (get startLine of selection) of front window as string end if end tell tell application "R64" cmd the_selection end tell I don't know if that sheds any light on the situation. I do like TextWrangler but can't use it because any time I send a plot command over it plots fine with Quartz, but when I close the window (manually or with dev.off()) I get the segfault. Rob Goedman-3 wrote: > > John, > > To the best of my knowledge this problem in R.app has been around at > least since the R-2.8 days, but likely much longer. I never use R from > a Terminal, so don't know if it occurs or not outside R.app. > > It's not related to Rcmdr and you're observation is indeed one of the > better ways to kind of reproduce the issue. Not sure if it always does > though. If you have a 'hard' way of crashing R.app, please let me know > the sequence. In cases when no output is written to the console of > R.app I tend to make sure I enter an empty line before closing the > graphics window. > > This issue and sometimes very long sequences of plots (never have been > able to make that reproducible, sometimes the crash happens up to a > minute after R finishes a series of plots and I'm working in an > external editor like TextMate) are hard to pin down. > > Regards, > Rob > > Note: Hope you don't mind I've removed the R-bugs & R-devel Cc's. > > On Apr 30, 2009, at 6:29 AM, John Fox wrote: > >> Dear Neil, >> >> I had R 2.8.0 installed on my Mac Book, also with OS X 10.5.6, and was >> unable to duplicate this problem. I then installed R 2.9.0 and >> observed the >> same problem that you did. In both cases, I used the latest version >> of the >> Rcmdr package, 1.4-10. >> >> I also observed the following: (1) The problem occurred only if I >> closed the >> Quartz graphics device after the first graph was plotted; if I plotted >> another graph and then closed the device, the problem did not occur. >> (2) The >> problem did not occur if I ran R from a terminal with an X11 >> graphics device >> rather than using R.app. >> >> I'm afraid that there's not much more that I can do at this point, >> since my >> familiarity with Macs is minimal. I'm copying this message to Rob >> Goedman, >> who has proven helpful in the past. Of course, if there's something >> in the >> Rcmdr that's causing the problem and I can fix it, I will. >> >> Regards, >> John >> >> >>> -Original Message- >>> From: r-devel-boun...@r-project.org >>> [mailto:r-devel-boun...@r-project.org >>> ] >> On >>> Behalf Of nhepb...@ualberta.ca >>> Sent: April-28-09 1:25 PM >>> To: r-de...@stat.math.ethz.ch >>> Cc: r-b...@r-project.org >>> Subject: [Rd] crash after using graphics in Rcmdr (PR#13679) >>> >>> Full_Name: Neil Hepburn >>> Version: 2.81 and 2.90 >>> OS: OS-X 10.5.6 >>> Submission from: (NULL) (142.244.28.93) >>> >>> >>> When I create graphs using Rcmdr and then close the quartz display, R >> blows >>> up >>> and tells me of a segmentation fault. It then gives me >>> *** caught segfault *** >>> address 0xc023, cause 'memory not mapped' >>> >>> 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: >>> >>> This only happens if I create the graphics from within Rcmdr. If I >>> create >> the >>> graphics manually, there is no problem. This occurs on my laptop >>> with R >> 2.8.1 >>> (I >>> uninstalled 2.9 and reinstall 2.8.1 to see if the problem existed >>> there) >> and >>> also on my iMac with R2.9. >>> >>> __ >>> 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 > > -- View this message in context: http://www.nabble.com/crash-after-using-graphics-in-Rcmdr-%28PR-13679%29-tp23312961p23337174.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
