Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <56CCFDD2.4000102@gmail.com>
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 15:39:59 +0900
Message-ID: <CAGa2bXbapR+mgUvJ6fTHo3DDt7FK7P9Avby+scD4dgXaBah5iw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

On Wed, Feb 24, 2016 at 9:48 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> 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. You certainly don't want var_dump to print that by default - this
> would make display cluttred and have very high WTF factor - why I
> entered 0.1 and get this enormous snake of a number? PHP must be broken!
> Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
> want to see 8 or 7.99999999999999911182158029987476766109466552734375?
>
> In fact, when we represent 0.1 as 0.1 when serializing our outputting,
> we are not discarding information, on the contrary - we are preserving
> exactly the information that was given to us by user.
>
>> 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?
>
>> 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. 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.
>
>> 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. Sometimes we have no choice but to take decisions with this
> incomplete knowledge - but here we have a perfectly good option of just
> leaving it alone. All other options should be weighted against it.

This discussion is related to

https://wiki.php.net/rfc/precise_float_value

If you have comment on this, I appreciate it.
Please search old thread for discussions.
I'll start final RFC discussion for this when session RFC is finished.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net