On Wednesday, 19 June 2024 at 20:14, Claude Pache <claude.pa...@gmail.com> 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
