Folks,
My r-base package fails during 'make check' on Arm. One of the upstream
authors kindly helped in debugging this (and thanks to Phil for creating an
account for him).
As shown below, the issues seems to be the non-standard treatment of NaN
values. Has think come up from other packages? Does anybody here see a
workaround, or have other suggestions?
Thanks, Dirk
----- Forwarded message from Peter Dalgaard BSA <[EMAIL PROTECTED]> -----
Envelope-to: [EMAIL PROTECTED]
Delivery-date: Sat, 05 Jan 2002 15:58:35 -0600
To: Dirk Eddelbuettel <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Kindly asking for another Arm account
From: Peter Dalgaard BSA <[EMAIL PROTECTED]>
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> On Sat, Jan 05, 2002 at 05:01:25PM +0100, Peter Dalgaard BSA wrote:
> > Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> >
> > > Hi Peter
> > >
> > > And happy New Year. As for this arm bug, I can't find you mail to me on
> > > the
> > > is_na/is_nan macros. Did you get any further? Is there a patch you want
> > > me
> > > to try, or further info Phil B. could provide?
> >
> > I don't think we can get any further. The Arm floating-point system
> > seemed to be behaving so far from IEEE specs that it would be a major
> > effort to get anything to work properly. I think this needs to be
> > resolved at the kernel/glibc level and that is hardly within our
> > capacity.
>
> Noted, and I don't disagree. Wonder how to best enforce this -- should
> configure fail when arm is detected? Or should I simply exclude arm from
> the list of build architectures?
[CC'ing r-core for info]
The latter, I think.
I poked around a bit further, but there seems to be a lot of
weirdness:
(gdb) p R_NaReal
$4 = NaN(0x7a2)
(gdb) p R_NaN
$5 = -NaN(0xfffffffffffff)
(gdb) p R_NaN * 2
$6 = 2.1214777255866187e-314
(gdb) p 0./0. * 2
$7 = NaN(0x200000)
(gdb) p 0./0.
$8 = NaN(0x100000)
So some numbers that are NaN can be operated upon and then become
numbers? But it it is not like we arecoding R_NaReal in a format that
isn't an IEEE NaN, as I hoped for a while...
> Dirk
>
> > So I suggest we just leave the platform as unsupported. If all
> > machines of that architecture are as slow as medusa, I don't think
> > there would me much of a market for R there anyway.
> >
> > Then again, after a little web searching: There is something with a
> > peculiarity of the byte-ordering on arm being a mixture of big- and
> > little-endian. Maybe I/we should give it another shot.
> >
> > The basic issue is that R's NA is not getting treated as a NaN value
> > and code all over the place is relying on that, e.g.:
> >
> > > x<-NA
> > > x*2
> > [1] 8.29488e-311
> > > x
> > [1] NA
> >
> > --
> > O__ ---- Peter Dalgaard Blegdamsvej 3
> > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
> > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> > ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
> --
> Good judgment comes from experience; experience comes from bad judgment.
> -- F. Brooks
>
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
----- End forwarded message -----
--
Good judgment comes from experience; experience comes from bad judgment.
-- F. Brooks
