1. nan (was: math.e and misc.e)
Jason Gade wrote:
> Bernie Ryan wrote:
>
>> I think the floating point hardware will return NaN.
>
> Yes, but NAN can be more than one value, as can inf. Right now I have a
> working
> type definition for isnan(x) and I'll also do one for isinf(x). The names can
> be changed, of course.
This is the isnan() function which I wrote some years ago:
global function isnan (object x)
-- return TRUE, if and only if x is an IEEE 754 NaN value
sequence bits, mantissa
integer exponent
if sequence(x) then return FALSE end if
bits = atom_to_bits64(x)
-- check exponent and mantissa
exponent = bits_to_int(bits[53..63]) - 1023
if exponent = 1024 then
mantissa = bits[1..52]
if not equal(mantissa, repeat(0,52)) then
return TRUE
end if
end if
return FALSE
end function
Regards,
Juergen
2. Re: nan (was: math.e and misc.e)
Juergen Luethje wrote:
>
> Jason Gade wrote:
>
> > Bernie Ryan wrote:
> >
> >> I think the floating point hardware will return NaN.
> >
> > Yes, but NAN can be more than one value, as can inf. Right now I have a
> > working
> > type definition for isnan(x) and I'll also do one for isinf(x). The names
> > can
> > be changed, of course.
>
> This is the isnan() function which I wrote some years ago:
> }}}
<eucode>
> global function isnan (object x)
> -- return TRUE, if and only if x is an IEEE 754 NaN value
> sequence bits, mantissa
> integer exponent
>
> if sequence(x) then return FALSE end if
>
> bits = atom_to_bits64(x)
>
> -- check exponent and mantissa
> exponent = bits_to_int(bits[53..63]) - 1023
> if exponent = 1024 then
> mantissa = bits[1..52]
> if not equal(mantissa, repeat(0,52)) then
> return TRUE
> end if
> end if
> return FALSE
> end function
> </eucode>
{{{
>
> Regards,
> Juergen
Thanks, Juergen. That's a nice implementation. Of course, you would have to have
atom_to_bits64() defined somewhere...
Will stuff like this work for what has been discussed, with regards to error
values?
--
"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.
3. Re: nan (was: math.e and misc.e)
Jason Gade wrote:
> Thanks, Juergen. That's a nice implementation. Of course, you would have to
> have atom_to_bits64() defined somewhere...
>
> Will stuff like this work for what has been discussed, with regards to error
> values?
Hmm. Like many things, doing a search through the archives finds the use of NAN
as an error flag has been discussed before.
http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=3&fromYear=8&toMonth=8&toYear=8&postedBy=&keywords=nan
Why oh why do I have such a problem with information retention? ;)
--
"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: nan (was: math.e and misc.e)
Jason Gade wrote:
> Thanks, Juergen. That's a nice implementation. Of course, you would have to
> have atom_to_bits64() defined somewhere...
Ooops.
Sorry. The following is working code:
include machine.e
global function atom_to_bits64 (atom a)
-- return the bit representation of an IEEE
-- double precision floating point number
sequence s, bits
s = atom_to_float64(a)
bits = {}
for i = 1 to 8 do
bits &= int_to_bits(s[i], 8)
end for
return bits
end function
global function isnan (object x)
-- return TRUE, if and only if x is an IEEE 754 NaN value
-- [nach PowerBASIC 3.0 Benutzer-Handbuch, S. 272 f.;
-- Goldberg: http://docs.sun.com/source/806-3568/ncg_goldberg.html]
sequence bits, mantissa
integer exponent
if sequence(x) then return 0 end if
bits = atom_to_bits64(x)
-- check exponent and mantissa
exponent = bits_to_int(bits[53..63]) - 1023
if exponent = 1024 then
mantissa = bits[1..52]
if not equal(mantissa, repeat(0,52)) then
return 1
end if
end if
return 0
end function
-- Demo
constant
POS_INF = 1.8e+307 * 10, -- Positive Infinity value (IEEE 754)
SUB_NAN = -(POS_INF-POS_INF), -- "Not a Number" values (IEEE 754)
DIV_NAN = -(POS_INF/POS_INF),
MUL_NAN = -(0*POS_INF)
? isnan(27)
? isnan(POS_INF)
? isnan(SUB_NAN)
? isnan(DIV_NAN)
? isnan(MUL_NAN)
Regards,
Juergen
5. Re: nan (was: math.e and misc.e)
Thanks. I *am* working on compiling all of this stuff into a limits.e file...
It should have:
Max integer value
Max atom value
normalized min atom value
denormalized min atom value
-- which of these to should actually be ATOM_MIN? in C, it is the normalized
number that is defined as the min and I don't see the denormalized number
anywhere.
atom epsilon -- smallest precise atom scaled to 1.0
Matt's get_epsilon() and next_higher_atom() and next_lower_atom() functions.
is_nan()
is_infinite()
NAN_Q -- defined as a quiet NAN that can be assigned to atoms
INFINITY
Anything else?
--
"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.
6. Re: nan (was: math.e and misc.e)
Jason Gade wrote:
> Thanks. I *am* working on compiling all of this stuff into a limits.e file...
Nice idea.
> It should have:
> Max integer value
> Max atom value
> normalized min atom value
> denormalized min atom value
> -- which of these to should actually be ATOM_MIN? in C, it is the normalized
> number that is defined as the min and I don't see the denormalized number
> anywhere.
> atom epsilon -- smallest precise atom scaled to 1.0
> Matt's get_epsilon() and next_higher_atom() and next_lower_atom() functions.
>
> is_nan()
> is_infinite()
>
> NAN_Q -- defined as a quiet NAN that can be assigned to atoms
> INFINITY
>
> Anything else?
MIN_INTEGER = #C0000000 -- = -power(2,30)
Currently no other values come to my mind in this regard.
Regards,
Juergen
7. Re: nan (was: math.e and misc.e)
Juergen Luethje wrote:
> MIN_INTEGER = #C0000000 -- = -power(2,30)
Now there's a mistake I've made quite a few times recently
The above is of course +3221225472, instead use any of:
-#40000000, #C0000000-#100000000, -1073741824, or -power(2,30).
Regards,
Pete
8. Re: nan (was: math.e and misc.e)
Pete Lomax wrote:
>
> Juergen Luethje wrote:
>
> > MIN_INTEGER = #C0000000 -- = -power(2,30)
>
> Now there's a mistake I've made quite a few times recently
>
> The above is of course +3221225472, instead use any of:
> -#40000000, #C0000000-#100000000, -1073741824, or -power(2,30).
>
> Regards,
> Pete
Nice point, Pete. I made the same mistake at least once while trying to figure
these things out.
--
"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.
9. Re: nan (was: math.e and misc.e)
Pete Lomax wrote:
> Juergen Luethje wrote:
>
> > MIN_INTEGER = #C0000000 -- = -power(2,30)
>
> Now there's a mistake I've made quite a few times recently
>
> The above is of course +3221225472, instead use any of:
> -#40000000, #C0000000-#100000000, -1073741824, or -power(2,30).
Uuuuh! It's not the first time that I walked into this trap.
Thanks for the correction.
Regards,
Juergen