On Wednesday, 19 June 2024 at 20:14, Claude Pache <[email protected]> wrote:
> Hi,
>
> Naming is hard, for sure. Here is my review. I find the names mostly reasonable, except
> Round::PositiveInfinity and Round::NegativeInfinity. I will discuss Round::PositiveInfinity.
>
> First:
>
> > I've discussed this with Saki. In that case the HalfEven and
> > HalfOdd modes would also need to be renamed to HalfTowardsEven and
> > HalfTowardsOdd
>
>
> For me, the implied preposition in HalfEven is “to”, not “towards”. In
> other words, in the HalfEven mode, a half-number 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::HalfEven is fine; but Round::PositiveInfinity does not make much
> sense to me, as the number is not rounded to +∞, but towards +∞.
>
I agree with this part.
> -------
>
> Second, “TowardsPositiveInfinity” is just a mouthful synonym for “Up”. You could just
> name it:
>
> Round::Up
>
> At this point, you may invoke either Hamming or Levenshtein and compare it negatively with
> Round::HalfUp. Yes there is a risk a confusion (and I do 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 most important part of my review.
I disagree there, the main motivation of the RFC is to fix the naming of PHP_ROUND_HALF_UP because
it does *not* match the mathematical behaviour of rounding half toward positive infinity.
And considering multiple other programming languages *also* have made that mistake I do not think
that “TowardsPositiveInfinity” is a synonym for "Up".
Moreover, I'm not sure something being a mouthful is a good reason to name it something else.
>
> -------
>
> In my opinion, the most important criterion for a good name is:
>
> The name must be clear for itself, not just when comparing it with other ones.
>
> The problem with Round::Up (or Round::[Towards]PositiveInfinity),
> when you first encounter it, is that it is relatively easy to mistakingly assume that it is a
> “half-*” mode, and to erroneously interpret it as Round::HalfUp (or, its synonym
> Round::HalfTowardsPositiveInfinity).
>
> But that the converse is false: it is impossible to interpret Round::HalfUp as if
> it were Round::Up (or Round::TowardsPositiveInfinity), because of the
> distinctive “Half” token that immediately indicate the right interpretation.
>
> So, the best way to disambiguate Round::Up from Round::HalfUp, is not
> to replace “Up” with some creative synonym, but to add a distinctive token that plays the role
> of — and contrasts with — “Half”. I don’t know if the following suggestion makes sense for
> you, but it is the one I have found:
>
> Round::FullUp
>
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 focus of rounding is how to break ties, not about the
rounding itself.
Moreover, and this is the part where I think the naming of “TowardsPositiveInfinity” is better,
is because you said yourself that:
> the implied preposition in HalfEven is “to”, not “towards”
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.
> ---------
>
> That said, I think that there is an even better option. I know you will not like it, but bear
> with me. I sincerely think that the best name is just:
>
> Round::Ceiling
>
> It is short, distinctive, and standard across the computing industry.
>
> Yes, this name is idiosyncratic to English and not used in several other (natural) languages,
> and if you don’t know English, you will not grasp the metaphor and have to just learn it. However,
> whatever other name you invent, you have to learn “ceil” anyway, because you will encounter it
> sooner or later. Many common (programming) languages, including JavaScript, C++, Java, Python, have
> a ceil function. Even if you manage not to learn any of those and to code in PHP only,
> you are at risk to stumble on its built-in ceil(...) function, or its newly-introduced
> bcceil(....) variant.
>
> Therefore, unless we find a name that is really good, I suggest to not fall into the NIH
> syndrome, and not to force users to learn another name in addition to “ceiling”.
>
I don't see how this falls into the NIH syndrome, because it has not been invented here.
The terminology chosen is standard in mathematics, and even more so in mathematical speech in other
languages.
Best regards,
Gina P. Banyard