Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58580
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: "Pierre Joye" <pierre.php@gmail.com>, "Anthony Ferrara"
 <ircmaxell@gmail.com>
Cc: internals@lists.php.net
References: <CAAyV7nHajQqw5tsQh=eZWhxtotQqNx03sd=FDTbcu10nUuNxtA@mail.gmail.com> <op.wanfhc15idpuyk@damnation.nl.lo.geleia.net> <CAEZPtU6hFQcJAS80embbgUJLsF11eunBT9y5j4OD1NmV_HNK4w@mail.gmail.com> <CAAyV7nF73MYpabTiU75YZB43ste5jfsd8_biCvgzYda6sYdxkw@mail.gmail.com>
Date: Sun, 04 Mar 2012 16:29:30 +0100
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.wanjzgleidpuyk@damnation.nl.lo.geleia.net>
In-Reply-To: <CAAyV7nF73MYpabTiU75YZB43ste5jfsd8_biCvgzYda6sYdxkw@mail.gmail.com>
User-Agent: Opera Mail/11.61 (Win32)
Subject: Re: [PHP-DEV] Patches for Review
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Sun, 04 Mar 2012 15:02:23 +0100, Anthony Ferrara <ircmaxell@gmail.com>  
wrote:

>>> In sum, I think the rule that if a mathematical operation involves a  
>>> float, the result should be a float ought to be kept.
>>
>> Yes, it is a must.
>
> Well, I'm not so sure about that.
>
> If you look at the docs of pow(), it describes the return type as
> "base raised to the power of exp. If the result can be represented as
> integer it will be returned as type integer, else it will be returned
> as type float.".
>
> That's not the current behavior.  pow((float) 2, 1) returns float(2).
> If you want to update the docs instead of the code, then that's fine.

You're reading too much into the documentation. The intention of that  
phrase seems to be if the result overflows, it will a float instead (just  
like when you add two large integers, for instance).

Yes, the plain text doesn't preclude your interpretation, but it's not  
supported by the implementation or the general behavior of mathematical  
operators in PHP. By all means, change it in order to make it more clear.

> However, this can lead to precision loss in a number of cases (like
> pow(2, (float) 55) which is not representable exactly by a float, and
> hence cause data-loss.  Whereas converting to an integer allows (on 64
> bit platforms) an exact representation.

You're making a critical error here. float(55.) is in fact different from  
int(55). Float values have a rounding error associated, while integers  
don't. The accuracy of float(55.) is 14.2142, which means the uncertainty  
is 6.10623*10^-15, or that float(55.) = 55 +- 3.05311*10^-15.

Mathematical operations will only increase the (relative) error and  
therefore decrease the precision. This is an example with Mathematica's  
arbitrary precision numbers (NOT machine precision numbers, even though  
I'm setting the arbitrary precision to $MachinePrecision); this keeps  
track of the accumulated errors:


In[30]:= SetPrecision[55, $MachinePrecision] // Precision
Out[30]= 15.9546
In[31]:= 2^SetPrecision[55, $MachinePrecision] // Precision
Out[31]= 14.3734

This means that if you do 2^55., the result will have total uncertainty:

In[34]:= 2^SetPrecision[55, $MachinePrecision] // 10^-Accuracy[#] &
Out[34]= 152.492

Take your example:

var_dump((int) (pow(2, (float) 55) - 1));

You're adding 1 to a result that has a total uncertainty of more than  
152... It's pointless, don't you think?

Of course, PHP doesn't keep track of errors, and the reason subtracting 1  
has no effect is because the rounding error itself in the result is  
already larger than 2:

In[45]:= 2^55. // 10^-Accuracy[#] &
Out[45]= 4.

> [...]
> Additionally, I thought the whole point of type juggling in PHP was
> such that the type didn't matter?  So that a float and an int are the
> same from a usage standpoint?

This is a very vague statement. "Doesn't matter" for what? We have  
different types for integers and floats, 1. and 1 are different things and  
this is reflected in several places. What type juggling does is that one  
*one specific type is expected*, but another one is given, PHP tries to  
convert the result. This doesn't mean the types are "implementation  
details".

> But this is a case where the exact same
> input (just type is different) leads to different output.  Which I
> believe is inconsistent and incorrect.
>
> But if the consensus is otherwise, that's fine...
>

-- 
Gustavo Lopes