Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121008
MIME-Version: 1.0
References: <CAPTD5yEcwBNUe2Y9vvmHaigFtvRixJ0anTuLk4zXOKvBhrUOig@mail.gmail.com>
 <7f23f0ac-bba6-5997-b737-2a252205cf85@bastelstu.be> <CAAwdEzDGa+16bc0Hhmnzau6vkGpfRFqiRetw7V7KGbjsTyS8Cg@mail.gmail.com>
In-Reply-To: <CAAwdEzDGa+16bc0Hhmnzau6vkGpfRFqiRetw7V7KGbjsTyS8Cg@mail.gmail.com>
Date: Thu, 7 Sep 2023 10:10:11 -1000
Message-ID: <CAMrTa2ECWas1MwsUhsLjDUpj1dxikBdCj4CVwcqUFi+2hT-tyA@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Jorg Sowa <jorg.sowa@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003c0f5f0604ca7392"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add 4 new rounding modes to round() function
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000003c0f5f0604ca7392
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 3, 2023 at 5:51=E2=80=AFAM Alexandru P=C4=83tr=C4=83nescu <drea=
lecs@gmail.com>
wrote:

> Hi!
>
> On Sun, Sep 3, 2023 at 3:14=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:
>
> >
> > The RFC mentions already has a section with regard to naming:
> >
> >  > Why not the names PHP_ROUND_UP and PHP_ROUND_DOWN
> >
> > I generally agree with the argument in favor of the names you've chosen=
.
> > However they are inconsistent with the existing 'PHP_ROUND_HALF_UP' /
> > DOWN constants.
> >
> > I don't want to create extra work for you, but I wonder if additionally
> > one of the following should be done:
> >
> > - Creating PHP_ROUND_HALF_AWAY_FROM_ZERO as an alias for
> > PHP_ROUND_HALF_UP (and likewise for HALF_DOWN).
> >
> >
> I believe consistency is important and using UP for "away from zero" and
> DOWN for "towards zero" sounds good to me. That was so far used
> consistently everywhere, as far as I'm aware.
> Documentation is very clear about what they mean, and you can always thin=
k
> that both positive infinity and negative infinity are up while zero is
> down.
>
> Yes, we can have some extra constants for the four ones that contain "up"
> or "down" with "away from zero" and "towards zero", but I find it
> unnecessary.
>

As someone who maintains a math library in PHP that has its own expanded
rounding implementation, I will politely disagree. Away from zero, towards
zero, towards positive infinity, and towards negative infinity are
completely and utterly unambiguous and provide the developer with precise
control over what behavior they want. I don't see a reason to use something
that we KNOW is ambiguous when we're designing it.

This becomes even more important if we ever wanted to provide even more
rounding modes. For instance, a PHP_ROUND_HALF_ALTERNATING would want to
explicitly use positive and negative infinity as its directions most
likely. (The purpose of a "half alternating" mode is to ensure that the
introduced error by rounding many numbers doesn't have a directional bias
by swapping between two modes that round in one direction and then the
other.)

I don't want to complicate this RFC, but I wouldn't mind adding a
PHP_ROUND_STOCHASTIC mode later either. (This mode would round 1.7 to 2 for
70% of executions and 1 for 30% of executions. The purpose of this rounding
mode is to ensure that if you averaged the same number being rounded over
and over, it would average to your original unrounded number, and is used
in many Machine Learning applications.)

Jordan

--0000000000003c0f5f0604ca7392--