develooper Front page | perl.perl5.porters | Postings from February 2015

Re: some thoughts on inf and nan

Thread Previous | Thread Next
From:
Jarkko Hietaniemi
Date:
February 9, 2015 03:16
Subject:
Re: some thoughts on inf and nan
Message ID:
54D8268F.4000701@iki.fi
On Saturday-201501-17 14:30, Jarkko Hietaniemi wrote:
> On Saturday-201501-17 14:08, Kent Fredric wrote:
>> feel like there should be some sort of SNAN/QNAN flag and payload
>> preservation, including some sort of support for getting that payload
>
> There's no need for a flag, I think, isnan() works.  But there are
> multiple loose ends, admittedly.

Now, as of 
http://perl5.git.perl.org/perl.git/commit/0d1cf11425608e9be019f27a3a4575bc71c49e6b 
there's more... stuff.

* payload can now be specified with "nan(0x...)"
* "nans" is now understood - but beware of the semantics,
   "nans(0)" really is "inf"... or, possibly "-inf"

The nan payload is really off the deep end of the floating
point pool.

The exact bit patterns?  You don't want to know.

The amount of bits one can have in the payload: strictly
platform dependent and non-portable. (32 is safe-ish bet,
though.)

What I have now seems to cover sane-ish little and big endians,
with 64-bit or 80-bit NVs, and with 32-bit or 64-bit UVs.
Double-double platforms and mixed endians are unsupported
for now.  (Don't even have access to the latter.)  I ran out
of time and tuits, and the Damoclean blade of 5.22 swings near.

What I would really like to do is a proper Configure dive
for these features, but there's no time, and I would like
to have a better understanding of what to scan for.

> The snan/qnan difference is painful because AFAICT different platforms
> have different rules, and the actual behavior is also up to the
> platforms.

Oh, indeed.  I found a lot of crazy on the platforms that I had
access to, so there's guaranteed to be more on those I hadn't.

> What Perl should do about signaling nans?  I dunno.  The whole IEEE
> fp semantics are a little bit unhelpful if considering interpreters as
> opposed to "native".  SIGFPE?  What does that even mean in Perl terms?
> My "+" failed, what do I do next?

My answer for now: Perl does nothing, except shuffle bits on or off.

In general, the 'signaling' feature seems to be little used in real
implementations.

> The payload can be in theory *set* via POSIX::nan() (C99 nan()),
> as "nan(deadbeef)", but we do not currently implement that.  Where the
> payload is supposed to be *read*, well, I dunno.

Since the libc (or libm) nan() seemed to be so ... unfinished... in
so many platforms, the POSIX::nan() now drops through to the Perl core
implementation.

For output, I hijacked the 'alt' or '#' flag (e.g. %#g): for NaN values,
it now shows the payload.



Thread Previous | 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