Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100531
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
To: Sara Golemon <pollita@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <a022f556-c3c1-ea17-5db8-18261f8032e5@gmx.de>
 <CAESVnVrWZrB7+9X73p9o0_-L8k+zTgmGsXgmodLsBrBrn_xn_g@mail.gmail.com>
Message-ID: <a7397cd6-666b-b9b0-f5e8-f0cabd091064@gmx.de>
Date: Tue, 12 Sep 2017 01:11:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVrWZrB7+9X73p9o0_-L8k+zTgmGsXgmodLsBrBrn_xn_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] BCMath and floats
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 11.09.2017 at 19:13, Sara Golemon wrote:

> On Mon, Sep 11, 2017 at 8:36 AM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>> I already have proposed to introduce bcinit() which would take a string,
>> int or float, and return a properly formatted string with the given or
>> default scale, see <https://github.com/php/php-src/pull/2746>.  Nikita
>> suggested to accept the arguments allowed by `bcinit()` for all
>> functions in the first place.  This would, however, raise the question
>> which scale should be applied to floats.
>
> I agree with Nikita.  Given that current behavior for floats passed to
> bc*() obey EG(precision), I'd say we should retain that behavior in
> these explicit conversions.  That way existing (functional) uses
> aren't impacted, we just quietly start working on other cases (where
> scientific notation and/or non-period delimiters would have been
> used).

Okay, that makes sense.

>> Before proceeding to an RFC (if necessary at all), I'm looking forward
>> to hear your thoughts regarding this topic.
>>
> IMO, this falls under fixing an existing bug (bc*() functions don't
> accept certain types of floats), so it wouldn't need an RFC to be
> accepted.  I would wait a little bit to get feedback on the scale
> question before merging though.  I would even offer that we could
> apply this to 7.[012] safely.

Hmm, the bc*() functions are documented to accept strings, and as such
there is no actual bug; see also Mike's final assessment on
<https://bugs.php.net/55160>.  If we would consider this as bug, we also
had to consider some other cases regarding our peculiar float to string
casting behavior as bug.  And even if we would, we still couldn't
generally change the float to string cast for BC reasons easily (if ever).

Anyhow, I'll gladly wait for further comments. :)

-- 
Christoph M. Becker