IEEE NaN problems on Arm (as triggered by the r-base package)
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 <p.dalgaard@biostat.ku.dk> -----
Envelope-to: edd@edd.debian.net
Delivery-date: Sat, 05 Jan 2002 15:58:35 -0600
To: Dirk Eddelbuettel <edd@debian.org>
Cc: r-core@r-project.org
Subject: Re: Kindly asking for another Arm account
From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
Dirk Eddelbuettel <edd@debian.org> writes:
> On Sat, Jan 05, 2002 at 05:01:25PM +0100, Peter Dalgaard BSA wrote:
> > Dirk Eddelbuettel <edd@debian.org> 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
> > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) 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
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
----- End forwarded message -----
--
Good judgment comes from experience; experience comes from bad judgment.
-- F. Brooks
Reply to: