Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91368
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <A0.38.38634.0530DC65@pb1.pair.com>
To: internals@lists.php.net
References: <CAF+90c_1zO91x-4Madqm3F8gkKDT7jZKVZSbBuYMbnDCADrv_A@mail.gmail.com>
 <47.95.38634.798BCC65@pb1.pair.com> <56CCFDD2.4000102@gmail.com>
Date: Wed, 24 Feb 2016 01:11:40 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0)
 Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <56CCFDD2.4000102@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1
From: ajf@ajf.me (Andrea Faulds)

Hi Stas,

Stanislav Malyshev wrote:
> Hi!
>
>> foot, by discarding possibly important information when serialising - an
>> operation that's supposed to perfectly reproduce a value!
>
> I'm not sure this is correct. Also, for values that are not exactly
> representable in binary, I'm not sure you want to see
> 0.1000000000000000055511151231257827021181583404541015625 instead of
> 0.1.

This assumes we would print an exact decimal representation, but that's 
far more than necessary. In order to get the same result when converted 
back to a float, we need at most 17 digits. In many cases we don't even 
need to show 17, because there are not that many digits in a 
full-precision decimal representation (e.g. 0.5). We could use less in 
many cases if PHP were to switch to the approach other languages use, 
where we output only the shortest sequence of digits producing the same 
value when converted back to a float (whereas currently we output in 
full precision, up to 17 significant figures).

> You certainly don't want var_dump to print that by default - this
> would make display cluttred and have very high WTF factor

Why would displaying at most three extra digits have a "high WTF factor"?

> - why I
> entered 0.1 and get this enormous snake of a number?
  PHP must be broken!

var_dump() is a debugging function. If it shows a value, it must 
represent it accurately. Otherwise:

$ php -r 'var_dump(1.00000000000002, 1.00000000000001, 1.00000000000001 
=== 1.00000000000002);'
float(1)
float(1)
bool(true)

Please explain to me why this is intuitive and reasonable behaviour for 
a debugging function.

Furthermore, if PHP developers find floating-point confusing and are 
genuinely surprised that 0.1 cannot be represented in binary exactly, 
then perhaps they should go and learn about what floating-point numbers 
do, rather than naïvely continuing on thinking they're decimals thanks 
to PHP lying to them! It is not the job of the language to try and hide 
that floats are imprecise from programmers.

> Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
> want to see 8 or 7.99999999999999911182158029987476766109466552734375?

Let's look at what our contemporary programming languages do.

Python:

 >>> 8.2 - 0.2
7.999999999999999

JavaScript:

8.2 - 0.2
7.999999999999999

That's much shorter than your suggestion.

Heck, let's look at what var_export() does:

$ php -r 'var_export(8.2 - 0.2);'
7.9999999999999991

Still a lot shorter.

> In fact, when we represent 0.1 as 0.1 when serializing our outputting,

But we don't represent 0.1 as 0.1:

$ php -r 'var_export(0.1);'
0.10000000000000001

> we are not discarding information, on the contrary - we are preserving
> exactly the information that was given to us by user.

$ php -r 'var_dump(1.00000000000002);'
float(1)

That doesn't look very preserved to me.

>
>> print floats to their full precision - including in var_dump(). This can
>> create unreasonable confusion when debugging (why are two numbers that
>> appear identical with var_dump() reported as inequal?), means
>
> You really think that displaying 8.2 - 0.2 as 8 is more confusing than
> displaying it as 7.99999999999999911182158029987476766109466552734375?

It's more *honest*. If two values are different, they should not be 
displayed the same.

And, again, the result would not be that large:

$ php -r 'var_export(8.2 - 0.2);'
7.9999999999999991

>
>> potentially important information is removed by default, and really
>> ought not to be a global setting anyway: if you want to format your
>> numbers with reduced precision, do so explicitly.
>
> That would mean optimizing for case that nobody wants, and de-optimizing
> case that pretty much everybody wants.

Who wants to round numbers to the same precision in all situations, for 
all apps running on their server, for all code running within a given 
request, even in libraries?

> Ask 100 people using PHP what
> they want as a result of 8.2 - 0.2 and count how many of them want to
> see full-precision monster of a number.

"7.9999999999999991" isn't that monstrous, and it could be even less so 
if PHP used a nicer float-to-string conversion approach.

>
>> There might be others worth dealing with, too, these are just the first
>> three I thought of.
>
> I would very much advise not to mess with any options until we are
> definitely, 100%, without any doubt sure that nobody needs to use it for
> anything. Removing options earns us nothing in terms of functionality.
> If nobody uses them - ok, fine - drop them. If we need to remove them
> e.g. because component they address goes away or changes function in a
> way that makes it irrelevent - fine, drop them. But doing it just
> because very small number of people that we can engage in discussion on
> the list (and that's not going to ever change - PHP user community is
> vastly larger than people even reading this list, let alone actively
> participating in it) think it's not needed IMHO is a very wrong
> approach.

This might be a fine argument, but I'm not arguing these settings are 
not needed. I'm arguing they're actively harmful.

-- 
Andrea Faulds
https://ajf.me/