Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51438
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <op.vqj8xup0idpuyk@damnation>
 <843E1DDB7AB24D9FA8F05801FE45202A@pc>
 <AANLkTikM957a-wWGgVsM9hXTUofbFiS4ZivkfQ-6rskm@mail.gmail.com>
Date: Tue, 08 Feb 2011 23:43:00 -0000
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.vqlytttbidpuyk@damnation>
In-Reply-To: <AANLkTikM957a-wWGgVsM9hXTUofbFiS4ZivkfQ-6rskm@mail.gmail.com>
User-Agent: Opera Mail/11.01 (Linux)
Subject: Re: [PHP-DEV] Change default serialize precision from 100 to 17
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Tue, 08 Feb 2011 20:05:05 -0000, Nicolas Grekas  
<nicolas.grekas+php@gmail.com> wrote:

>> ini_set('precision', 17);
>
> After some testings, here is what I get :
>
> <?php
>
> ini_set('precision', 14);
> echo 0.1; // 0.1
> echo 0.2; // 0.2
> echo 0.3; // 0.3
>
> ini_set('precision', 17);
> echo 0.2; // 0.10000000000000001
> echo 0.2; // 0.20000000000000001
> echo 0.3; // 0.29999999999999999
>
>
> The default precision of 14 (or 12) must have been chosen to address
> this overlong string representation of many simple floats ?
> While I agree with you that any data loss must be forbidden, couldn't
> this also break existing code ?

Yes, I think it's dangerous to change the default display precision lest  
we have a ton of applications that currently show 0.2 showing  
0.20000000000000001.

> Would it be possible to "displays a value based on the shortest
> decimal fraction that rounds correctly back to the true binary value",
> like python 2.7 and 3.1 do ?
> (http://docs.python.org/tutorial/floatingpoint.html)
>

This may be a good idea for trunk, but I don't think it's feasible for 5.3  
for the same reason. Showing "shortest decimal fraction that rounds  
correctly back to the true binary value" works fine for numbers that are  
directly input, where the only error is the normal rounding error (i.e.,  
total uncertainty for x is x*2^-53). Once you start making calculations  
with the numbers the errors start being propagated, so in these scenarios  
you would still end up with a lot more "ugly" string representations that  
you have today with the default display precision.

I agree that the information loss in e.g. PDO must be fixed, but it seems  
more appropriate to fix those problems by forcing another precision only  
in those cases.

-- 
Gustavo Lopes