Maths.Round() should accept negative numbers

bgrommes

Currently there's no native way to round a number to the nearest 100, 1000, etc. This isn't a frequent need but it has happened to me more than once over the years.

I have always thought that rounding methods should take zero (round to integer) or negative numbers (-1 for nearest 10, -2 for nearest 100, etc) and FoxPro (and IIRC, the xBase language family in general) used to do this. Admittedly no non-dead language that I know of, lol. But it was darned useful.

I have a data export requirement at work for example that has strange rounding rules that involve rounding to the nearest 1,000 10,000 or 100,000, etc. depending on how big a number is (has to do with presenting business tradelines in that vendor's preferred manner). And this is all on hot paths.

Of course you can do this with division / multiplication tricks, e.g.

Maths.Round(someValue / 100) * 100

... but in a bytecode environment I'd prefer this be handled as optimally as possible under the hood. Also it seems like a nice ease-of-use convenience for a language with Objo's ease-of-use ethos.

Garry

Good suggestion. This has now been implemented and will be included in the next release: https://feedback.objo.dev/feature/1243

Negative decimal places round to powers of ten:

Maths.Round(12345, -1)     # 12340
Maths.Round(12345, -2)     # 12300
Maths.Round(12345, -3)     # 12000

The same behaviour is available through Double.Round():

12345.0.Round(-2)          # 12300

It preserves Objo’s existing ties-to-even rounding:

Maths.Round(1250, -2)      # 1200
Maths.Round(1350, -2)      # 1400

Both forms use the same native implementation, avoiding the manual divide/round/multiply workaround. Thanks for the suggestion!

bgrommes

Garry You're too good to us, my dude!

I must say that I never use banker's rounding by default. I do it the way I was taught in grade school, which is .5 rounds up, everything else rounds down (though the case of negative numbers was not contemplated in that tutelage).

Even though I work in fintech (though admittedly, not specifically in banking), a client has never either specified or requested this be done differently.

So not to take this post back off your to-do list, lol -- is there any chance we could have access to options here, such as the MidpointRounding enum used to pick rounding strategies in Math.Round() in C#? Those strategies are:

ToEven (banker's rounding -- and, admittedly, the default)
AwayFromZero (the one I normally use, and the default in some other languages, like JavaScript)
ToZero (similar to Truncate())
Down (similar to Floor())
Up (similar to Ceiling())

Personally I would be happy with just the first two, given that Objo has dedicated functions for the others anyway, and I think that's even the way most C# coders would go for that functionality.

It think this is also kind of important for inter-language compatibility; if I'm talking to a system that uses AwayFromZero, I shouldn't be using banker's rounding.

Garry

Yes, I think that’s a reasonable addition. I’ve accepted it to the roadmap: https://feedback.objo.dev/feature/1246

The rounding mode will be optional, with ties-to-even remaining the default. Existing and simple calls will therefore remain unchanged:

value.Round()
value.Round(2)
Maths.Round(value)
Maths.Round(value, 2)

Callers needing ties-away-from-zero will be able to request it explicitly:

value.Round(.AwayFromZero)
value.Round(2, .AwayFromZero)

Maths.Round(value, .AwayFromZero)
Maths.Round(value, 2, .AwayFromZero)

I agree that supporting ToEven and AwayFromZero initially provides the useful distinction without unnecessarily duplicating Floor(), Ceiling(), and Truncate().

One minor correction: JavaScript doesn’t quite use away-from-zero rounding. Its midpoint ties go towards positive infinity, so Math.round(-3.5) produces -3, whereas away-from-zero would produce -4. Your wider interoperability point is entirely valid, though as code sometimes needs to match the rounding policy of another system explicitly.

Garry

As of the next release Round() now supports a midpoint rounding mode 🙂

The Round() functions on Double, Maths, and Currency now let you choose how exact midpoint values are rounded, via a new RoundingMode enum:

RoundingMode.ToEven — exact midpoints round to the even result (ties-to-even, banker's rounding). This is the default.
RoundingMode.AwayFromZero - exact midpoints round away from zero, on both sides of zero.

Existing calls are completely unchanged: value.Round(), value.Round(2), Maths.Round(value), and Maths.Round(value, 2) all keep their current behaviour.

Print(2.5.Round())                # 2   (ties-to-even, the default)
Print(1.25.Round(1))              # 1.2
Print(1250.0.Round(-2))           # 1200

When you need a different policy, pass the mode explicitly - for whole numbers, for a specific number of decimal places, and for negative decimal places (powers of ten) alike:

Print(2.5.Round(RoundingMode.AwayFromZero))         # 3
Print((-2.5).Round(RoundingMode.AwayFromZero))      # -3
Print(1.25.Round(1, RoundingMode.AwayFromZero))     # 1.3
Print(1250.0.Round(-2, RoundingMode.AwayFromZero))  # 1300

Print(Maths.Round(2.5, RoundingMode.AwayFromZero))          # 3
Print(Maths.Round(1.25, 1, RoundingMode.AwayFromZero))      # 1.3
Print(Currency.Parse("4.50").Round(RoundingMode.AwayFromZero))  # 5

The selected policy applies consistently for positive, zero, and negative decimal-place counts, and NaN, infinities, and signed-zero sign behave exactly as before under either policy.

Passing RoundingMode.AwayFromZero is useful when you need to match external systems that round ties away from zero, while the simple value.Round(...) API keeps its familiar ties-to-even default.