1. limits.e (was: NAN)
- Posted by Jason Gade <jaygade at ?ah?o.com>
Aug 09, 2007
-
Last edited Aug 10, 2007
Okay, I've written and tested this and I think that it's correct. I need to pay
better attention to my sig...
I'll put it in the upload area if anyone is interested:
http://www.rapideuphoria.com/uploads/limits.e
I found that on Windows running the interpreter, you *can* compare two NANs for
equality. I'll have to check with the translator and on Linux whether that is
also true.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
2. Re: limits.e (was: NAN)
Jason Gade wrote:
>
> Okay, I've written and tested this and I think that it's correct. I need to
> pay better attention to my sig...
>
> I'll put it in the upload area if anyone is interested:
> <a
> href="http://www.rapideuphoria.com/uploads/limits.e">http://www.rapideuphoria.com/uploads/limits.e</a>
>
> I found that on Windows running the interpreter, you *can* compare two NANs
> for equality. I'll have to check with the translator and on Linux whether that
> is also true.
>
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
You can always do that. But does a NaN equal itself? According to IEEE 754
standards, it shouldn't.
And if it does, it means some machine code has to be used to test for NaN (bit
patterns may differ across architectures). Not much, but a little.
CChris
3. Re: limits.e (was: NAN)
CChris wrote:
>
> Jason Gade wrote:
> >
> > Okay, I've written and tested this and I think that it's correct. I need to
> > pay better attention to my sig...
> >
> > I'll put it in the upload area if anyone is interested:
> > <a
> > href="http://www.rapideuphoria.com/uploads/limits.e">http://www.rapideuphoria.com/uploads/limits.e</a>
> >
> > I found that on Windows running the interpreter, you *can* compare two NANs
> > for equality. I'll have to check with the translator and on Linux whether
> > that
> > is also true.
>
> You can always do that. But does a NaN equal itself? According to IEEE 754
> standards,
> it shouldn't.
Yes, I know it's not supposed to work that way.
I did something like this:
a = ATOM_INFINITY
b = -ATOM_INFINITY
c = 0.0 * a -- should make a NAN
d = a + b -- should make a NAN
if c = d then
puts(1, "They are equal!\n")
end if
Then I pretty printed their float64 values in hex and saw that they were both
FFF8000000000000 which is a quiet NAN.
It's not a big deal -- it's a behavior that should not be relied upon. I just
want to test and document whether Windows and Linux and translated code have
different or the same behaviors.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
4. Re: limits.e (was: NAN)
Jason Gade wrote:
>
> CChris wrote:
> >
> > Jason Gade wrote:
> > >
> > > Okay, I've written and tested this and I think that it's correct. I need
> > > to
> > > pay better attention to my sig...
> > >
> > > I'll put it in the upload area if anyone is interested:
> > > <a
> > > href="http://www.rapideuphoria.com/uploads/limits.e">http://www.rapideuphoria.com/uploads/limits.e</a>
> > >
> > > I found that on Windows running the interpreter, you *can* compare two
> > > NANs
> > > for equality. I'll have to check with the translator and on Linux whether
> > > that
> > > is also true.
> >
> > You can always do that. But does a NaN equal itself? According to IEEE 754
> > standards,
> > it shouldn't.
>
> Yes, I know it's not supposed to work that way.
> I did something like this:
> }}}
<eucode>
> a = ATOM_INFINITY
> b = -ATOM_INFINITY
> c = 0.0 * a -- should make a NAN
> d = a + b -- should make a NAN
> if c = d then
> puts(1, "They are equal!\n")
> end if
> </eucode>
{{{
>
> Then I pretty printed their float64 values in hex and saw that they were both
> FFF8000000000000 which is a quiet NAN.
>
> It's not a big deal -- it's a behavior that should not be relied upon. I just
> want to test and document whether Windows and Linux and translated code have
> different or the same behaviors.
>
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
I see...
Then we can only count on the hardware. I have an asm routine to do this (for
80387 and onboard FPUs), which I wrapped so as to use it thru call(). I can post
it if there's any interest.
CChris
5. Re: limits.e (was: NAN)
CChris wrote:
> I see...
> Then we can only count on the hardware. I have an asm routine to do this (for
> 80387 and onboard FPUs), which I wrapped so as to use it thru call(). I can
> post it if there's any interest.
>
> CChris
Well, the is_nan() function that I wrote in limits.e works pretty good for all
values of NAN from 0x7ff0000000000001 to 0x7fffffffffffffff, including negatives.
It's not as fast as machine code but I don't expect is_nan() to be used in a
tight performance loop. If I had to do that then I'd probably just write an
assembly or C routine anyway.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
