Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123729
Date: Fri, 21 Jun 2024 13:20:47 +0000
To: Claude Pache <claude.pache@gmail.com>
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, Saki Takamachi <saki@sakiot.com>, Jorg Sowa <jorg.sowa@gmail.com>, php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum
Message-ID: <hMKWNZpIbLXd6x9iv4BtuR49cYIm7-H92jwF7S-YpUmHLV9nPymvTPrdMZ5Pnfr2ovl22RL4LBly2soz72DywYagpoXArKG1-vPP3cM67I8=@gpb.moe>
In-Reply-To: <0A9642EC-0FCC-4BC3-82C2-C6C968CD8D1C@gmail.com>
References: <9zUVZKaEYixjCLLhviQPYFQtSAEhsRMWL6xbKeogzAGsH-STebN9JqJxITAPVfdKTNu7gEs_m77OkIcOzaiscoajx8Hp8VWRKkhTTCPkGko=@gpb.moe> <6E690732-8BED-4A01-8385-648E7CEDFD9F@sakiot.com> <70f63dd2e0ba7959a9e3bb7fa68ce14a@bastelstu.be> <CJrCSLTp-erzdhSRTrFn2Ss0AoEpkkhqh7fnUrXgHyMfgNPkwXhpSeGsKdhV_ycUIqWhJWpWOxI0W8XGprR_O8iqSrVVWoBNiUUFMaZCNDY=@gpb.moe> <67d37d56-625f-4f80-805d-a5db2d3807bb@bastelstu.be> <0A9642EC-0FCC-4BC3-82C2-C6C968CD8D1C@gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Wednesday, 19 June 2024 at 20:14, Claude Pache <claude.pache@gmail.com> =
wrote:

> Hi,
>=20
> Naming is hard, for sure. Here is my review. I find the names mostly reas=
onable, except Round::PositiveInfinity and Round::NegativeInfinity. I will =
discuss Round::PositiveInfinity.
>=20
> First:
>=20
> > I've discussed this with Saki. In that case the `HalfEven` and `HalfOdd=
` modes would also need to be renamed to `HalfTowardsEven` and `HalfTowards=
Odd`
>=20
>=20
> For me, the implied preposition in `HalfEven` is =E2=80=9Cto=E2=80=9D, no=
t =E2=80=9Ctowards=E2=80=9D. In other words, in the HalfEven mode, a half-n=
umber is replaced with the nearest even integer; it is not replaced with a =
integer in the direction of (or: towards) an even integer. So, `Round::Half=
Even` is fine; but `Round::PositiveInfinity` does not make much sense to me=
, as the number is not rounded to +=E2=88=9E, but towards +=E2=88=9E.
>=20

I agree with this part.

> -------
>=20
> Second, =E2=80=9CTowardsPositiveInfinity=E2=80=9D is just a mouthful syno=
nym for =E2=80=9CUp=E2=80=9D. You could just name it:
>=20
> Round::Up
>=20
> At this point, you may invoke either Hamming or Levenshtein and compare i=
t negatively with `Round::HalfUp`. Yes there is a risk a confusion (and I d=
o think that such a name is suboptimal for this reason), but the confusion =
is not just caused by the short Levenshtein distance. That brings to the mo=
st important part of my review.


I disagree there, the main motivation of the RFC is to fix the naming of PH=
P_ROUND_HALF_UP because it does *not* match the mathematical behaviour of r=
ounding half toward positive infinity.
And considering multiple other programming languages *also* have made that =
mistake I do not think that =E2=80=9CTowardsPositiveInfinity=E2=80=9D is a =
synonym for "Up".
Moreover, I'm not sure something being a mouthful is a good reason to name =
it something else.

>=20
> -------
>=20
> In my opinion, the most important criterion for a good name is:
>=20
> The name must be clear for itself, not just when comparing it with other =
ones.
>=20
> The problem with `Round::Up` (or `Round::[Towards]PositiveInfinity`), whe=
n you first encounter it, is that it is relatively easy to mistakingly assu=
me that it is a =E2=80=9Chalf-*=E2=80=9D mode, and to erroneously interpret=
 it as `Round::HalfUp` (or, its synonym `Round::HalfTowardsPositiveInfinity=
`).
>=20
> But that the converse is false: it is impossible to interpret `Round::Hal=
fUp` as if it were `Round::Up` (or `Round::TowardsPositiveInfinity`), becau=
se of the distinctive =E2=80=9CHalf=E2=80=9D token that immediately indicat=
e the right interpretation.
>=20
> So, the best way to disambiguate `Round::Up` from `Round::HalfUp`, is not=
 to replace =E2=80=9CUp=E2=80=9D with some creative synonym, but to add a d=
istinctive token that plays the role of =E2=80=94 and contrasts with =
=E2=80=94 =E2=80=9CHalf=E2=80=9D. I don=E2=80=99t know if the following sug=
gestion makes sense for you, but it is the one I have found:
>=20
> Round::FullUp
>=20

This is an interesting point of view, but what this tell me is not an issue=
 with Up or Down on its own, but that seemingly for you and others the focu=
s of rounding is how to break ties, not about the rounding itself.

Moreover, and this is the part where I think the naming of =E2=80=9CTowards=
PositiveInfinity=E2=80=9D is better, is because you said yourself that:

> the implied preposition in `HalfEven` is =E2=80=9Cto=E2=80=9D, not =
=E2=80=9Ctowards=E2=80=9D

Which, at least to me, also implies that if you see something that includes=
 "Towards" you stop thinking about the tie breaking behaviour and thus just=
 think about the total/complete rounding behaviour.

> ---------
>=20
> That said, I think that there is an even better option. I know you will n=
ot like it, but bear with me. I sincerely think that the best name is just:
>=20
> Round::Ceiling
>=20
> It is short, distinctive, and standard across the computing industry.
>=20
> Yes, this name is idiosyncratic to English and not used in several other =
(natural) languages, and if you don=E2=80=99t know English, you will not gr=
asp the metaphor and have to just learn it. However, whatever other name yo=
u invent, you have to learn =E2=80=9Cceil=E2=80=9D anyway, because you will=
 encounter it sooner or later. Many common (programming) languages, includi=
ng JavaScript, C++, Java, Python, have a `ceil` function. Even if you manag=
e not to learn any of those and to code in PHP only, you are at risk to stu=
mble on its built-in `ceil(...)` function, or its newly-introduced `bcceil(=
...)` variant.
>=20
> Therefore, unless we find a name that is really good, I suggest to not fa=
ll into the NIH syndrome, and not to force users to learn another name in a=
ddition to =E2=80=9Cceiling=E2=80=9D.
>=20

I don't see how this falls into the NIH syndrome, because it has not been i=
nvented here.
The terminology chosen is standard in mathematics, and even more so in math=
ematical speech in other languages.

Best regards,

Gina P. Banyard