Reply to topic  [ 2 posts ] 
NAN value anf %f format 
Author Message
Yorick Guru

Joined: Thu May 10, 2007 12:07 pm
Posts: 62
Post NAN value anf %f format
On my mac intel :
> s = "2.3  4.5 NAN 8.0"
> a = array(double, 4)
> sread, s, a
> write, a, format="%e "
2.300000e+00 4.500000e+00 nan 8.000000e+00
> write, a, format="%g "
2.3 4.5 nan 8
> write, a, format="%f "
2.300000 4.500000 ERROR (*main*) Floating point interrupt (SIGFPE)
WARNING source code unavailable (try dbdis function)
now at pc= 1 (of 15), failed at pc= 9
To enter debug mode, type <RETURN> now (then dbexit to get out)

the format %f do not like NAN value. Is it normal ? I expected the same behavior than %e %g format.

Wed Nov 19, 2008 7:24 pm
Yorick Master

Joined: Mon Nov 22, 2004 9:43 am
Posts: 354
Location: Livermore, CA, USA
NaN is unfortunately accepted by by versions of the ANSI C scanf functions, and translated into some kind of NaN (there is a signalling NaN and a non-signalling NaN, one of which corresponds to many different bit patterns). Once you get a NaN into a floating point array, it is like a disease that spreads, often throughout all your arrays. Yorick (and all well built numerical software) handles the SIGFPE generated whenever a NaN is used in any arithmetic operation, or, in the case of a signalling NaN, when it is even loaded into a floating point register. I don't know which path triggeres the SIGFPE in the ASNI printf function that you see, and it doesn't matter. Yorick is blowing up with SIGFPE the instant it detects that you have caught the lethal NaN disease, correctly avoiding it from spreading and destroying your entire calculation. This way, death occurs immediately after the infection, and you can see that your program caught the disease with the preceding read (scanf).

There are many similar bugs in the fscanf/fprintf function family, some of which are even required by the ANSI C standard. (I don't know if the scanf bug you found is required by the ANSI C standard, or is merely the misguided attempt to follow some other standard -- notably the pure evil IEEE 754 standard.) In any event, the correct fix for this problem is to rewrite the unreliable scanf function, so that the string "NAN" is not accepted as a legal number. That would have caused your read to fail. Since either way, your program would not have run correctly, and since yorick correctly blew up at its first opportunity and alerted you to the problem, this is not a bug in my opinion. Even if you judge it a bug, the bug is in the libc scanf function, not in yorick. So report it to the gcc people, and they can refer you to the IEEE 754 standards committee. Good luck there. The now defunct DEC pulled their representative out of that committee after a ten year battle to make the 754 standard viable for numerical software, which is the event that triggered the final approval of that disastrous standard, which makes it impossible to write portable high performance numerical software.

Sat Nov 29, 2008 9:42 am
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.