Hi
please apologize the delay in getting back to you. I was absolutely
swamped with mailing list mails, other work and I didn't want to give a
reply that I did not give any thought.
On 6/19/24 21:14, Claude Pache wrote:
Second, “TowardsPositiveInfinity” is just a mouthful synonym for “Up”. You
could just name it:
Round::Up
Except that it isn't and both the RFC and the two fine folks who already
replied explained why.
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.
Please note that the comparison was not made against the corresponding
“Half” mode, but rather that the term “Up” is needlessly ambiguous. As
I've also replied to Jordan: The RFC intentionally does not use the Up
terminology (except to refer to the existing constants, which
unfortunately use that terminology).
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`).
That is a fair concern. We shortly discussed splitting the enum into one
"MidpointRoundingMode" and one other enum for the directed rounding
modes, but we felt that it did not reliably solve this problem either.
At least with a single enum all the 'Half' modes would appear in
autocompletion.
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.
Right.
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
You might have misunderstood my email. The concerns were not that
HalfTowardsZero is too similar to TowardsZero, but rather that
HalfTowardsZero is too similar to HalfTowardsEven, because they share
the same 11-character prefix.
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”.
There is precedent for an "infinity-based" naming in other programming
languages. The most mainstream one is probably C#:
https://learn.microsoft.com/en-us/dotnet/api/system.midpointrounding?view=net-8.0
But there is also MATLAB:
https://de.mathworks.com/help/matlab/ref/round.html#mw_e51282fd-7461-4bab-9f38-6106551bb8b2
We can even find precedent in PHP itself. The GMP extension already has
rounding mode constants GMP_ROUND_PLUSINF and GMP_ROUND_MINUSINF:
https://www.php.net/manual/en/gmp.constants.php
And to add some anecdata: Just a few days ago I fixed a bug where the
floor() function was incorrectly used where rounding towards zero was
desired, resulting in incorrect results for negative numbers.
The Ceiling / Floor / Up / Down naming is needlessly ambiguous,
especially for non-native speakers.
For the same reason, `Round::TowardsZero` (suboptimal, because confusable with
`Round::HalfTowardsZero`) could be replaced with: `Round::Truncate`.
While I think that Truncate is reasonably clear, breaking the mapping
between the midpoint modes and the directed rounding modes just for this
case does not appear useful.
Best regards
Tim Düsterhus
