IEEE NaN screwed up?

[ivowel]

dear perl wizards:

perl v5.8.5, gentoo linux:

my $v="NA"; my $x= $v+1.0; print $x; --> some error about adding
strings
my $v="NaN"; my $x= $v+1.0; print $x; --> 1

this seems wrong. adding a NaN and a number should be a NaN; $v should
not be interpreted as 0. am I missing something obvious?

sincerely,

/iaw

 

[attn.steven.kuo]

dear perl wizards:

perl v5.8.5, gentoo linux:

my $v="NA"; my $x= $v+1.0; print $x; --> some error about adding
strings
my $v="NaN"; my $x= $v+1.0; print $x; --> 1

this seems wrong. adding a NaN and a number should be a NaN; $v should
not be interpreted as 0. am I missing something obvious?

sincerely,

/iaw

See:

$ perldoc bignum

$ perldoc bigint

$ perl -Mbignum -le 'print NaN + 1.0'
NaN


Note that NaN is not a quoted string.

 

[ivowel]

hi steven:

yes it does help, because I now know that I need BigFloat, but the perl
default treatment still seems like a big. if NaN is the IEEE quantity
(or something similar), then $x should be NaN. if NaN is just a
string, then perl should give an error at the addition, just as it
would if the string were NA.

regards,

/iaw

 

[attn.steven.kuo]

hi steven:

yes it does help, because I now know that I need BigFloat, but the perl
default treatment still seems like a big. if NaN is the IEEE quantity
(or something similar), then $x should be NaN. if NaN is just a
string, then perl should give an error at the addition, just as it
would if the string were NA.

regards,

/iaw

Yes, if you're unfamiliar with
Perl internals, then the above
does seem confusing.

A scalar in Perl can be a string,
a number, or a string and a
number at the same time.


One can use the Devel:eek module
to look at the underlying structure
of a scalar (as it's "upgraded"
as the program advances).

Here's an example:


use strict;
use warnings;
use Devel:eek;


my $v = "NA";

Dump $v;

my $x = $v + 1.0; # warning expected

Dump $v;

$v = "NAN";

Dump $v;

$x = $v + 1.0; # no warning here!

Dump $v;



== The results (and my comments) ==

SV = PV(0xf5870) at 0xffb98
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
PV = 0xfbef0 "NA"\0
CUR = 2
LEN = 3

:: At this point $v is a string,
the scalar is a PV, and PV has
the value "NA". Thus we
see the following warning upon
attempted addition:


Argument "NA" isn't numeric in addition (+) at explain.pl line 11.


SV = PVNV(0x137a50) at 0xffb98
REFCNT = 1
FLAGS = (PADBUSY,PADMY,IOK,NOK,POK,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0xfbef0 "NA"\0
CUR = 2
LEN = 3

:: The attempt at addition, however,
causes the scalar to be upgraded to
a PVNV. Now the scalar has not
only the string representation,
"NA", but also numeric representations
in the NV and IV slots.



SV = PVNV(0x137a50) at 0xffb98
REFCNT = 1
FLAGS = (PADBUSY,PADMY,POK,pPOK)
IV = 0
NV = 0
PV = 0xfbef0 "NAN"\0
CUR = 3
LEN = 4

:: We reassign to the PV slot of
the scalar, replacing "NA" with "NAN".
The second attempt at addition, however,
produces no warnings.


SV = PVNV(0x137a50) at 0xffb98
REFCNT = 1
FLAGS = (PADBUSY,PADMY,IOK,NOK,POK,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0xfbef0 "NAN"\0
CUR = 3
LEN = 4


:: That because, the addition operation
is using the value in the NV slot
of the scalar -- which was initialized
to zero. 0 + 1.0 is 1.0; no warnings
because perl was trying to DWYM
(Do What You Meant).

 

[attn.steven.kuo]

(e-mail address removed) wrote:

(snipped)

One can use the Devel:eek module
to look at the underlying structure
of a scalar (as it's "upgraded"
as the program advances).

....


Bah! If I replace "NAN"
with "foo" then I get a
second warning about

Argument "foo" isn't numeric in addition (+) at explain.pl line 20

Ignore my last posting... there is
something different about "NAN". Sorry
about the misinformation.

 

[Sisyphus]

(e-mail address removed) wrote:

(snipped)

...


Bah! If I replace "NAN"
with "foo" then I get a
second warning about

Argument "foo" isn't numeric in addition (+) at explain.pl line 20

Ignore my last posting... there is
something different about "NAN". Sorry
about the misinformation.

Heh .... and it was such a well thought out and presented explanation, too


The IEEE 'NaN' has apparently been implemented in perl 5.8 (not 5.6) - but
only on platforms that support it, according to 'perldoc perlop'.
On such platforms, the statement:

if(NaN != NaN) {print "NaN supported"}

should produce "NaN supported".

Or, to quote it as it appears in perlop:

perl -le '$a = NaN; print "No NaN support here" if $a == $a'
perl -le '$a = NaN; print "NaN support here" if $a != $a'

I suspect that the inconsistent behaviour the op has reported is happening
on a platform that doesn't support NaN. I'm getting the same inconsistent
behaviour, and, according to the above test(s), my platform (Win32) doesn't
support NaN. I also tried on Linux, and got the same lack of support.

This doesn't seem right to me. If the platform doesn't support 'NaN', then
'NaN' should be just another string - or at least a warning should be issued
when 'NaN' is used in a numeric context on a platform that doesn't support
NaN. The porters should be informed. Who wants to do it ? (I will, if no-one
else wants to.)

Cheers,
Rob

 

[ivowel]

please do. I have no idea how to reach them.

regards,

/iaw

 

[attn.steven.kuo]

news:[email protected]...

[ snipped my well intended but faulty reasoning ]

Heh .... and it was such a well thought out and presented explanation, too

For some reason I thought the sequence:

$v = "NAN";
$v + 1.0;

would affect the scalar in the same way as:

use Scalar::Util qw(dualvar);
$v = dualvar 0, "NAN";

DWIM only goes so far, I guess.


[ more snipped ]

I suspect that the inconsistent behaviour the op has reported is happening
on a platform that doesn't support NaN. I'm getting the same inconsistent
behaviour, and, according to the above test(s), my platform (Win32) doesn't
support NaN. I also tried on Linux, and got the same lack of support.

This doesn't seem right to me. If the platform doesn't support 'NaN', then
'NaN' should be just another string - or at least a warning should be issued
when 'NaN' is used in a numeric context on a platform that doesn't support
NaN. The porters should be informed. Who wants to do it ? (I will, if no-one
else wants to.)

Seems like "INF" has the same behavior:

[sunnydale:~] skuo% perl -wle 'print "INF" + 1.0;'
1

[sunnydale:~] skuo% perl -wle 'print "foo" + 1.0;'
Argument "foo" isn't numeric in addition (+) at -e line 1.
1

[sunnydale:~] skuo% perl -v

This is perl, v5.8.6 built for darwin

Please do follow up with the P5P.

 

[Sisyphus]

please do. I have no idea how to reach them.

See http://lists.cpan.org/showlist.cgi?name=perl5-porters

That page contains a link to the Archive, where the thread I have just now
started (called "NaN on platforms that don't support it") can be viewed -
though I don't know how long it takes for posts to appear on the archive.

Cheers,
Rob

 

[Tassilo v. Parseval]

Also sprach Sisyphus:

See http://lists.cpan.org/showlist.cgi?name=perl5-porters

That page contains a link to the Archive, where the thread I have just now
started (called "NaN on platforms that don't support it") can be viewed -
though I don't know how long it takes for posts to appear on the archive.

It's often easier to simply use the 'perlbug' program that ships with
every perl. That way the report also gets assigned a bug ID and is
entered into the database of open issues.

Tassilo

 

[Sisyphus]

It's often easier to simply use the 'perlbug' program that ships with
every perl. That way the report also gets assigned a bug ID and is
entered into the database of open issues.

Good idea, so I gave it a whirl - but I'm on Win32 and it didn't work. The
report was prepared ok, but when it came to sending it I got:

Are you certain you want to send this message?
Please type "yes" if you are: yes
Died at D:/perl58_M/site/5.8.7/lib/Mail/Mailer.pm line 269, <STDIN> line 1.
Error removing C:\DOCUME~1\Rob\LOCALS~1\Temp\KSGmMCiup6 at
D:/perl58_M/5.8.7/lib/File/Temp.pm line 890, <STDIN> line 1.

The relevant part of Mailer.pm is:

268: # Fork and start a mailer
269: (defined($exe) && open($self,"|-"))
270: || $self->exec($exe, $args, \@to)
271: || die $!;
272:
273: # Set the headers
274: $self->set_headers($hdrs);

So it looks to me that the message didn't even get sent.

Since I still have that report I copied it into an email and sent it off to
(e-mail address removed) . Will that suffice ?

Cheers,
Rob

 

[Sisyphus]

Since I still have that report I copied it into an email and sent it off to
(e-mail address removed) . Will that suffice ?

Looks like that will suffice - judging by the autoreponse it generated which
says in part:

Your ticket has been assigned an ID of [perl #36654].

Cheers,
Rob

 

[Tassilo v. Parseval]

Also sprach Sisyphus:

Good idea, so I gave it a whirl - but I'm on Win32 and it didn't work. The
report was prepared ok, but when it came to sending it I got:

Are you certain you want to send this message?
Please type "yes" if you are: yes
Died at D:/perl58_M/site/5.8.7/lib/Mail/Mailer.pm line 269, <STDIN> line 1.
Error removing C:\DOCUME~1\Rob\LOCALS~1\Temp\KSGmMCiup6 at
D:/perl58_M/5.8.7/lib/File/Temp.pm line 890, <STDIN> line 1.

The relevant part of Mailer.pm is:

268: # Fork and start a mailer
269: (defined($exe) && open($self,"|-"))
270: || $self->exec($exe, $args, \@to)
271: || die $!;
272:
273: # Set the headers
274: $self->set_headers($hdrs);

So it looks to me that the message didn't even get sent.

Looks as if Mail::Mailer is botched. But then looking into Mail::Mailer,
I can't see how it could ever work on Windows.

Since I still have that report I copied it into an email and sent it off to
(e-mail address removed) . Will that suffice ?

Yes, it will. 'perlbug' only makes sure that the report has some
information attached that are vital for the bug hunters and sends it to
an address more suitable for reports.

Tassilo

 

[Sisyphus]

Looks as if Mail::Mailer is botched. But then looking into Mail::Mailer,
I can't see how it could ever work on Windows.

I suspect it doesn't work with Windows, though I didn't bother investigating
at all. Once the report is done it's no hassle to copy'n'paste into an email
and send it off, so I'll just settle for that.

Cheers,
Rob