Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121612
MIME-Version: 1.0
References: <FBFD1716-AD54-43C4-AF04-42AD9F3C5890@gmail.com>
 <095E59EE-173A-4114-AD3F-4B830CD2E295@sakiot.com> <2BD1AE90-F082-41AB-8F5E-7F5257142874@sakiot.com>
In-Reply-To: <2BD1AE90-F082-41AB-8F5E-7F5257142874@sakiot.com>
Date: Tue, 7 Nov 2023 20:42:16 +0000
Message-ID: <CAEKnhAGXnotsxHaAWxrkm42VdEg3XWHtJqKicG=F2CSS4P84dQ@mail.gmail.com>
To: Saki Takamachi <saki@sakiot.com>
Cc: Michael Wallner <mike@php.net>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000041f9ef06099602df"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()
From: bukka@php.net (Jakub Zelenka)

--00000000000041f9ef06099602df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

please do not top post - you might want to check these rules for PHP
mailing lists:
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md if you
haven't seen them already ;)

On Tue, Nov 7, 2023 at 4:07=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wro=
te:

> I have added as much of the rationale for the changes as I can think of t=
o
> the RFC. I would be happy if you could see it again.
>
>
It would be good to also mention original reasoning for preferring the
decimal edge cases. It says:

> Of course, one may argue that pre-rounding is not necessary and that this
is simply the problem with FP arithmetics. This is true on the one hand,
but the introduction of the places parameter made it clear that round() is
to operate as if the numbers were stored as decimals. We can't revert that
and this seems to me to be the best solutions for FP numbers one can get

I think it's got a good point with the second parameter and it's something
that voters should consider. You should not probably say that's current
implementation is wrong. It just chose to prefer decimal format and address
the edge cases explicitly in a way that it makes more sense to users.
Obviously it didn't fix all issues but we can potentially continue in that
approach which is what you did in one of your PR's - it would be good to
probably also note that such implementation is more complex.

Regards

Jakub

--00000000000041f9ef06099602df--