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

native floating point formatted I/O - prescriptive or descriptive?

Thread Next
From:
Jarkko Hietaniemi
Date:
September 9, 2014 14:48
Subject:
native floating point formatted I/O - prescriptive or descriptive?
Message ID:
540F131D.9030502@iki.fi
We have currently documented that for formatted floating point I/O we do 
whatever the native library does [1] [2]

Now, however, some of the work I've been doing lately collides with this 
promise.  If it is a promise.

Most immediately, the infinity/nan work.  Given how quirky the output 
formats of inf/nan is across platforms (inf INF Inf 1.#INF) I tried to
canonicalize to one (Inf and NaN).  But this of course will break if
there's something *outside* Perl that expects natively formatted
inputs.  (I'm not certain but I think Win32 strtod() doesn't do "Inf",
and POSIX strtod() certainly doesn't do "1.#INF").

We could come up with an API to output either "portable" or "native"
inf/nan.  (Personally I'm a little dubious about e.g. lexical pragmas
for such a trivial detail, I would prefer explicit functions.
And action-at-distance sucks.) Also, [3]

Furthermore: there are known problems with Perl's NV parsing (we do use 
our own atof clone): 
http://www.nntp.perl.org/group/perl.perl5.porters/2013/12/msg210443.html

And given that we do fallback to the native sprintf for floating point,
we indeed are at the mercy of whatever formatting it does.  (There are
enough not fully specified details that there are differences.)

One possible path forward with the above problems would be to start
using existing solutions for floating point formatted I/O.  I've done
some preliminary studies (for possibly using netlib gdtoa library) in 
https://rt.perl.org/Ticket/Display.html?id=122482  Doesn't look drop-in 
trivial, but feasible. It may not be perfect, but someone who knows what 
they are doing, has done it for us, and the code has been widely used 
elsewhere.

But using any new code for floating point formatted I/O would again
collide with the "Perl does whatever the underlying C library does".

So: is that a binding policy, or documenting what currently happens 
because history?

Let the bikeshedding games begin.

[1] perl.pod:

Perl is at the mercy of your machine's definitions of various
operations such as type casting, atof(), and floating-point
output with sprintf().

[2] perlfunc/sprintf:

Returns a string formatted by the usual C<printf> conventions of the C
library function C<sprintf>.  See below for more details and see 
L<sprintf(3)> or L<printf(3)> on your system for an explanation of
the general principles.

[3] Regarding NaN, there's an API that exists but only partially:
one can have "payload" in NaNs, google for "nan trick".  We currently
support setting the payload via POSIX::nan(), but do not support
setting the payload via string-to-nv parsing, or retrieving the payload, 
either explicitly, or via stringification.

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