What rounding modes to include?

[sffc]

ICU has the following options:

1. "halfUp" (default)
2. "halfEven"
3. "halfDown"
4. "ceiling"
5. "floor"
6. "up"
7. "down"

Chart: http://userguide.icu-project.org/formatparse/numbers/rounding-modes

Do we want to include all those in Intl.NumberFormat? How would we pick a subset?

@waldemarhorwat @littledan

[erights]

Is halfUp the same as "round to even"?

[sffc]

Is halfUp the same as "round to even"?

I think that would be halfEven. See the chart: http://userguide.icu-project.org/formatparse/numbers/rounding-modes

[littledan]

FWIW Java BigDecimal has basically the same set of modes, plus an UNNECESSARY mode which throws if rounding was needed. I don't know whether this was an independent invention, though, given that both of these projects had strong IBM involvement/authorship.

I suspect most of these are needed. The only two I'm suspicious of are floor and ceiling; I wonder if up and down would be enough (or, if floor/ceiling would be enough, without up/down). I'd like to collect more data somehow.

I tried to ask about rounding modes in the decimal survey but I haven't gotten any answers yet that really got at the semantics needed for negative numbers. I suspect negative numbers are important in some accounting/money use cases, though. Maybe this is something to follow up on in further interviews.

[waldemarhorwat]

Is halfUp the same as "round to even"?

No. halfUp will round ±0.5 to ±1, while halfEven will round ±0.5 to ±0.

The default internal IEEE arithmetic rounding is halfEven. The default rounding the IRS asks you to do on taxes is halfUp.

The set of modes here seems like one of the standard rounding repertoires and seems fine to me.

[sffc]

We should align the Intl rounding modes with the Decimal rounding modes. Perhaps this is a decision best made in the Decimal proposal, and the roundingMode option for 402 could piggy-back on that proposal instead of being in this proposal.

[waldemarhorwat]

@sffc: The Decimal rounding modes are the same as the various IEEE binary arithmetic rounding modes. They're part of the same standard and all have their uses.

[littledan]

Great, seems like we all agree that these two proposals should be aligned. (I agree that IEEE 754 is a good guide for rounding modes, but one possibility is that we could decide on a subset.)

[justingrant]

Some bikeshedding feedback on rounding mode names:

The only two I'm suspicious of are floor and ceiling; I wonder if up and down would be enough (or, if floor/ceiling would be enough, without up/down).

IMHO, the names "floor" vs. "down" and "ceiling" vs. "up" may confusingly similar for developers who may not be familiar with IEEE 754 or other platforms' rounding modes. Using all 4 terms may invite confusion.

My suggestion would be to align naming with existing methods used in JS's Math object. By using "trunc" instead of "down", it'd remove the ambiguity noted above. It's also probably better for JS developers if they can leverage existing knowledge of Math instead of having to learn a new (or slightly different) set of terms depending on which JS methods are being used. IMHO this is more important than aligning names to ICU or Java which will be less familiar to JS developers.

So:

• ciel (not "cieling")
• floor
• trunc (not "down")
• "round" is the difficult case because Math.round doesn't actually use any of the ICU modes-- it rounds -1.5 to -1, but 1.5 to 2. So if we had to break naming compatibility, this is probably the place. Perhaps using a prefix of "round" so developers will know that all of these are variations of Math.round-like behavior?
  • roundHalfCiel or perhaps just round - matches Math.round()
  • roundHalfEven - banker's rounding / IEEE default
  • roundHalfTrunc - this is ICU's "Half Down"
• I'm not sure "up" is an important enough use case to justify the possible confusion between whatever we call it and "ciel". But if someone can think of a non-confusing name, it'd be OK.

We should align the Intl rounding modes with the Decimal rounding modes.

I agree strongly that the same rounding modes and names should be used everywhere: Intl, Decimal, and Temporal.

One exception to alignment might be the default rounding mode used. For example, I could see Decimal's default being roundHalfCiel (because AFAIK that's the expected default for the main use case for Decimal which is financial calculations) while Temporal's default could be trunc (IMHO it would be weird to default to rounding half-days up to a full day without users opting into that behavior).

[sffc]

@gibson042 also suggested looking at the IEEE 754 list of rounding modes:

https://en.wikipedia.org/wiki/Floating-point_arithmetic#Rounding_modes

[gibson042]

There are already many behaviors in ECMA 262, and I believe each of them should be explicitly specifiable:

• Math.ceil "rounds" towards +∞ (ICU "Ceiling").
• Math.floor "rounds" towards -∞ (ICU "Floor").
• Math.trunc and abstract operation ToInteger "round" towards zero (ICU "Down").
• Math.round rounds ties towards +∞ (apparently not in ICU).
• Math.fround and internal conversions from mathematical values round ties to even, but ties relate to differences between arbitrary Number values rather than just integers (ICU "Half Even").

I find the ICU names confusing, and would not recommend using them; @justingrant's suggestions are better. If we include ICU "Up" then I would propose "awayFromZero", and likewise "halfAwayFromZero" or "tiesAwayFromZero" for ICU "Half Up".

[chyipin]

Wikipedia covers even more round options
https://en.wikipedia.org/wiki/Rounding

Up and Down is ambiguous: i.e. is the value or absolute value higher or lower

To explain ceil or floor, one typically uses round up or round down respectively (thus are synonymous).

I agree that the ICU usage for "Up" and "Down" is uncommon.

I like the recommendation for awayFromZero and possibly towardsZero.

[tabatkins]

For consideration, CSS's round() function chose the values nearest, up, down, and to-zero. (We leave open the possibility of adding away-from-zero later, but as it apparently wasn't useful enough to warrant a dedicated function in JS, we left it out for now.)

We haven't added finer modes for disambiguating nearest at half-integers (currently we always choose the up value), but the grammar is compatible with adding such switches later.

We purposely avoided floor/ceiling because ceiling is hard to spell, and we already had precedent for a similar feature in line layout using the up/down keywords.

(Having CSS's choices flow back into JS, when JS's choices originally informed much of them in this case, would be pretty funny to me.)