Front page | perl.perl5.porters |
Postings from August 2023
August 17, 2023 12:45
Message ID: 20230817144459.6d80becf@pc09
As mentioned on Amsterdam IRC by Johan (summarized):
sciurius: 'printf "%.2f\n", -1.785;' prints "-1.78" for >= 5.30 and "-1.79" for <= 5.28
We (Johan, Abe and me) have done some test to check if this was a
correct statement and if so, what part of the toolchain were to blame.
I used my perl farm to conclude:
-1.78 voor 5.6.0 … 5.8.0, -1.79 voor 5.8.1 … 5.29.1, -1.78 voor 5.29.2 … 5.38.1
Then I suggested that glibc/libm might be debet, but none of us could
find proof that the version of glibc had influence on this outcome.
I *know* that floats are imprecise, but I promised I'd forward this to
Abe then did a bisect to hit the culprit being
ce6f496d720f620645562842: PATCH: [perl #41202] text->float gives wrong answer
Again, *I* have no personal opinion or interest, but Rob and/or people
with knowledge in this area might have.
Author: Sisyphus <firstname.lastname@example.org>
Date: Wed Aug 1 22:33:38 2018 +1000
PATCH: [perl #41202] text->float gives wrong answer
This changes to use Perl_strtod() when available, and that turns out to
be the key to fixing this bug.
S_mulexp10() is removed from embed.fnc to avoid repeating the
complicated prerequisites for defining Perl_strtod(). This works
because this static function already was defined before use in
numeric.c, and always called in full form without using a macro.
James Keenan fixed a file permissions problem originally introduced by
this commit, but the fix has been squashed into it.
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org