develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About