Front page | perl.perl5.porters |
Postings from October 2013
Re: [perl #120405] Wrong results for unpack "f"
Thread Previous
|
Thread Next
From:
Slaven Rezic
Date:
October 29, 2013 12:43
Subject:
Re: [perl #120405] Wrong results for unpack "f"
Message ID:
87li1c45cs.fsf@biokovo.herceg.de
Tony Cook <tony@develop-help.com> writes:
> On Tue, Oct 29, 2013 at 10:06:30AM +0100, Lukas Mai wrote:
>> On 29.10.2013 10:00, slaven@rezic.de (via RT) wrote:
>> > # New Ticket Created by slaven@rezic.de
>> > # Please include the string: [perl #120405]
>> > # in the subject line of all future correspondence about this issue.
>> > # <URL: https://rt.perl.org/Ticket/Display.html?id=120405 >
>> >
>> >
>> > The problem is described in the StackOverflow article http://stackoverflow.com/questions/18969702/perl-strange-behaviour-on-unpack-of-floating-value
>>
>> Short version (copied into this bug for easier access):
>> -----------------------------------------------------------------------
>>
>> $ perl -e "print unpack('f>', pack ('f>', 279.117156982422));"
>> 279.617156982422
>
> I don't reproduce this here on Debian stable:
>
> tony@mars:.../git/bse$ ~/perl/5.18.0-thr/bin/perl -le "print unpack('f>', pack ('f>', 279.117156982422));"
> 279.117156982422
> tony@mars:.../git/bse$ perl -le "print unpack('f>', pack ('f>', 279.117156982422));"
> 279.117156982422
>
> perl -V output might be useful.
It's difficult to reproduce. Apparently it happens only on 32bit
systems. I created a CPAN distribution with this problem as a test case,
to get the results of CPAN testers, and there was only one fail report
at all (using Strawberry Perl under Windows 8.1 Preview). See here:
http://matrix.cpantesters.org/?dist=Acme-Study-SREZIC%202.00
http://matrix.cpantesters.org/?dist=Acme-Study-SREZIC%202.00;reports=1
And a direct link to the FAIL report (with perl -V included):
http://www.cpantesters.org/cpan/report/5f5ba05e-3e82-11e3-94cf-57ac40c32a75
Regards,
Slaven
>
>> Definitely a bug in Perl's unpacking. It has difficulty in handling
>> floats in the binary form xxxxyyFF at least in a 32-bit platform, where
>> 80 <= yy <= BF. The packed result will become xxxxzzFF, where zz = yy +
>> 40 (all in hexadecimal). And this is not a problem of endianness, as you
>> could see here:
>>
>> $ perl -e "print unpack('H8', pack ('f', unpack('f', pack('H8',
>> '000088ff'))));";
>> 0000c8ff
>
> I'm pretty sure this isn't a bug, but the FPU converting a signalling
> NaN into a quiet NaN, which the Intel CPU manual implies it does.
>
> ie. this might happen when the float from pack() is converted into
> double or long double, whichever representation perl uses for an NV.
>
> That said, the compiler might be depending on aliasing rules and
> loading afloat into an FPU register early, changing that code to use a
> union as was done in 275663fa07 for NVs might fix the problem.
>
> Tony
>
--
Slaven Rezic - slaven <at> rezic <dot> de
BBBike - route planner for cyclists in Berlin
WWW version: http://www.bbbike.de
Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
Thread Previous
|
Thread Next