[perl #38887] Result of INFINITY or NAN stringification is platform dependent

[Ron Blaschke]

I'm looking into this issue and would like to ask for some advice.

I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)

On Win32 the implementation is simple because the IEEE recommended
functions _finite and _isnan are supported. I'm thinking about adding a
test for these functions and use them. But what should happen if they
are not there?

Then I changed Parrot_sprintf_format in spf_render.c to use
Parrot_math_isnan and Parrot_math_finite to render "NaN", "-inf" and
"inf" directly.

Is this a good way to solve this?

Here's a sample (which should make its way into some tests):

>type test.pir
.sub main
# -INF
set N0, 0.0
ln N1, N0

print N1
print "\n"

# +INF
abs N2, N1

print N2
print "\n"

# NaN
set N3, -1.0
sqrt N4, N3

print N4
print "\n"
.end

# trunk
>parrot test.pir
-1.#INF00
1.#INF00
-1.#IND00

# local
>parrot test.pir
-inf
inf
NaN

Thanks,
Ron

[Bill Coffman]

On 7/26/06, Ron Blaschke <mailin...@rblasch.org> wrote:
>
> I'm looking into this issue and would like to ask for some advice.
>
> I have added the following platform dependent functions.
> int Parrot_math_isnan(double)
> int Parrot_math_finite(double)
>
> On Win32 the implementation is simple because the IEEE recommended
> functions _finite and _isnan are supported. I'm thinking about adding a
> test for these functions and use them. But what should happen if they
> are not there?
>
> Then I changed Parrot_sprintf_format in spf_render.c to use
> Parrot_math_isnan and Parrot_math_finite to render "NaN", "-inf" and
> "inf" directly.
>
> Is this a good way to solve this?

There is no platform independent way to produce "NaN" or "Inf", so IMHO, you
did it the only way it can be done.

That being said, you can optimize by looking at the bits. Wikipedia
explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754
First, you have to be aware if the machine is big or little-endian, second,
look at the exponent bits, if they are all set, this is not a normal number
(either +Inf, -Inf, or NaN, depending on mantissa and sign bit). Unless
you're targeting non-ieee-754 systems like the VAX (an old computer), this
is garanteed to be portable. I wouldn't bother with any platform specific
functions, as they are all different. Just look at the bits. (gcc uses
isnan, isinfinite, ... but I think you have to compile with the -c99 flag
and solaris does it a little different, etc).

I recently did something similar in PDL. If "looking at the bits" is not
helpful, I can give you a little more detail (hint "struct union"). If you
really don't want to look at the bits, I notice that gcc does have an
"isnormal()" function you can use, but again you have the portability
issues.

Personally, I'd like to see the "i" in "inf" capitolized or the "N"s in
"NaN" lower case. I like capital I for Inf.

Good luck,

--
Bill Coffman
~~~_\\\|/
~~~-(@ @)
=oOO=(_)==OOo===

[Ron Blaschke]

Bill Coffman wrote:
> There is no platform independent way to produce "NaN" or "Inf", so IMHO,
> you
> did it the only way it can be done.
>
> That being said, you can optimize by looking at the bits. Wikipedia
> explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754

Many thanks for your thoughts, Bill. Your suggestion seems a lot easier
than all this platform probing stuff I had in mind. For platforms that
don't use IEEE 754, like the VAX you mentioned, I guess we can always
come up with something else if the need arises.

> Personally, I'd like to see the "i" in "inf" capitolized or the "N"s in
> "NaN" lower case. I like capital I for Inf.

Sounds good to me. I'll change it to your suggested "Inf" and "NaN."

Thanks,
Ron

[Nicholas Clark]

On Wed, Jul 26, 2006 at 01:21:11PM -0700, Bill Coffman wrote:

> That being said, you can optimize by looking at the bits. Wikipedia
> explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754
> First, you have to be aware if the machine is big or little-endian, second,

Beware. It's legal for the endianness of the word order in memory to differ
from the endianness of the byte order within those words.

Nicholas Clark