On Wed, Jun 19, 2024 at 12:16 PM Claude Pache <claude.pa...@gmail.com> wrote:
> > 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. > > This is completely incorrect. "Up" is needlessly ambiguous. As evidence, I will quote from the CURRENT documentation for PHP: "PHP_ROUND_HALF_UP Rounds num away from zero when it is half way there, making 1.5 into 2 and -1.5 into -2" https://www.php.net/manual/en/function.round.php Clearly it is not "just a synonym", as the current PHP (incorrectly) equates "up" with "away from zero". It's the difference between rounding "up" in magnitude, and rounding "up" in value. Any discussion about "Hamming distance" utterly pales in the face of the reality that developers will be confused because we have trained them for 20 years to expect something else. People wanting to tab-complete faster is not a good argument in my opinion for doing something that will actively cause bugs and confusion about semantical meaning. "Up" and "Down" do not belong in a mathematical description of rounding where negative numbers exist, unless that term is consistent and WIDELY agreed on. However, to cause even FURTHER confusion, OTHER languages (such as the python function `round_up`) use "Up" to mean exactly what you are saying here: towards positive infinity. The fact that this is not a consistent terminology across languages that support rounding, AND the fact that PHP has for decades used "Up" to mean "Away from zero" makes this a complete non-started in my eyes. If there is ONE improvement to be made with this RFC, it is to completely remove "up" and "down" from the rounding terminology. Jordan
