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

2007-04-15 Thread Nicholas Clark
On Sun, Jul 16, 2006 at 12:49:27PM +0100, Ron Blaschke wrote:

> 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?

nan == nan isn't true, so that ought to be a portable test for a NaN
(although Intel's compiler's default optimisation setting is buggy in this
respect)

I don't know of a good way to test for inf.

Nicholas Clark



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

2006-08-19 Thread 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


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

2006-07-27 Thread 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


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

2006-07-26 Thread Bill Coffman

On 7/26/06, Ron Blaschke <[EMAIL PROTECTED]> 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,


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
~~~_\\\|/
~~~-(@ @)
=oOO=(_)==OOo===


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

2006-07-26 Thread 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


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

2006-07-16 Thread 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


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

2006-04-09 Thread via RT
# New Ticket Created by  Ron Blaschke 
# Please include the string:  [perl #38887]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38887 >


.sub main
# produce INFINITY (is there a constant for that?)
set N0, 0.0
ln N1, N0

print N1
print "\n"

# produce NAN (is there a constant for that?)
set N0, -1.0
sqrt N1, N0

print N1
print "\n"
.end

On Windows with Visual C++ 8.0 above code prints
>parrot test.pir
-1.#INF00
-1.#IND00

On UNIXish platforms it's probably "-inf" and "-nan".

That's why F currently fails on Windows: It expects
"-inf" on stringification.

t\pmc\complexok 13/50
t\pmc\complexNOK 30# Failed test (t\pmc\complex.t at line 997)
#  got: '
# ln(0+0i)
#   got -1.#INF00+0.00i
#   not -inf+0.00i
# done
# '
# expected: 'done
# '
t\pmc\complexok 50/50# Looks like you failed 1 test of 50.
t\pmc\complexdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 30
Failed 1/50 tests, 98.00% okay (less 3 skipped tests: 46 okay, 92.00%)
Failed Test Stat Wstat Total Fail  Failed  List of Failed
---
t\pmc\complex.t1   256501   2.00%  30
3 subtests skipped.
Failed 1/1 test scripts, 0.00% okay. 1/50 subtests failed, 98.00% okay.