Prev: Newbie: Regular expresion
Next: CGI and UTF-8
From: Ilya Zakharevich on 27 Sep 2009 20:01
On 2009-09-27, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> On 2009-09-27 02:46, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
>> On 2009-09-26, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>>> (The default perl FP->string conversion is a custom implementation
>>> (since the C library doesn't offer the functionality)
>>
>> C library definitely offers the functionality.
>
> Really? Which standard C function gives you the shortest decimal string
> representation of a floating point number which can be be converted back
> to an fp number with the same value?

Really? From when "The default perl FP->string conversion" follows
this requirement? See $# (sp?). [*]

[*] Of course, it is the ONLY sane semantic for Perl (see perldoc
perlnumber). However, AFAIK, it is not implemented.

Here is the history as I know it. About '96 somebody made a patch
which implemented *this* semantic. With a very noticable slowdown as
a side effect.

At the moment I had no idea how numbers are handled in Perl. When (in
2 or 3 years) I discovered what a mess it is (I wrote an automated
testing system, and about 60% of sanity tests were failing), I started
to fix it. Now: a part of the fix was a consistent caching of the
results of number-->string conversion [**].

[**] As a resent message about print() shows, it is not THAT
consistent now...

With *this* fix in place, switching to slower number-->string
conversion MIGHT have been cured of significant slowdowns. However,
myself, I never found tuits to check this.

Yours,
Ilya
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Newbie: Regular expresion
Next: CGI and UTF-8