develooper Front page | perl.perl5.porters | Postings from August 2014

some thoughts on inf and nan

Thread Next
From:
Jarkko Hietaniemi
Date:
August 20, 2014 16:54
Subject:
some thoughts on inf and nan
Message ID:
53F4D2A5.2050804@iki.fi
(Could I have some chicken korma with infinite naan, please?)

(How can you tell it's lunch time for me?)

I pushed a batch of changes to blead that try to robustify the C API we 
have for handling the "special values" of floating point: infinities and 
not-a-numbers.  There are also denormals, also known as subnormals, but 
I'm not going to talk about them now.  Neither am I going to talk about 
the negative zero.

...

But, so, inf and nan.

Bare inf doesn't work (1 + inf), since it gets parsed as string of 
numeric value of zero.  (p5p irc: "because barewords that don't match 
declared subs become strings ... see also one of mjd's recent blog 
posts")  Ditto for nan.

Now, how about having a core pragma, let's call it "infnan" (let the 
bike shedding begin), which declares those as subs, which return the inf 
or nan.

But even if we deal somehow with the 'literals', there is still the 
problem of input and output.

Output: we currently do whatever the native C printf does for inf and 
nan, and there, unfortunately, we have, ummm, a rich and varied 
tapestry.  Inf Infinity INF and ta-dah, Microsoft 1.#INF, and nan NaN 
NAN, and ta-dah, Microsoft 1.#QNAN 1.#SNAN and to top it all, 1.#IND
(see http://blogs.msdn.com/b/oldnewthing/archive/2013/02/21/10395734.aspx)

Input: the output in reverse - we use the native strtod() for inf and nan.

Possible output solution: have somewhere (the mythical infnan module?) 
helper interfaces that set the infnan stringification to either "native" 
or "portable" (Inf and NaN? -- another bikeshedding moment).

Possible input solution: hijack POSIX::strtod() to understand all these 
possible string forms?  I just did some refactoring towards this 
possibility: 
http://perl5.git.perl.org/perl.git/commitdiff/ff4eb3984da9fdf3cec4f01cf752e4e7da44139f

Possible downside of this input solution: is it bad that POSIX::strtod() 
no more would call the native C strtod()?  If it is, is there some other 
namespace we could use?  There's some stuff in Internals:: but that is 
not an inviting or obvious namespace.

Now that I think of it ... hijacking POSIX::strtod() to be more or less 
a shell for toke.c:scan_number (and the backing chorus of numeric.c) 
would also solve the previously discussed problem with underbars (that 
the default numification stops at underbars, and in fact at anything 
that isn't a decimal integer, with an optional fractional and exponent 
parts, like at hexadecimal literal-looking strings.)


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About