Money rounding mode

[bytecodeguru]

Looking at the code I've noticed that Money.toString uses the explicit rounding mode HALF_EVEN, while Money.toFormattedString does not. Is this the intended behaviour?

Speaking about rounding modes, I'd find useful a method to apply rounding to a Money instance. What I'm doing in my code right now is something like this:

implicit class MoneyOps(m: Money) {
  def rounded: Money = Money(
    value = m.amount.setScale(m.currency.formatDecimals, BigDecimal.RoundingMode.HALF_EVEN),
    currency = m.currency
  )
}

This may be useful to apply rounding in calculations on purpose.

[garyKeorkunian]

It appears the missing mode on toFormattedString was an oversight.

In fact, these may be switched. I think toFormattedString should apply the rounding, but toString should not - it should include the fully precise value. Thoughts on this?

I'll also take a look at the rounding method as well. It may be useful for any Quantity.

Quantities do have a map method that allows you to perform any operation on the underlying value, which can be used for a great number of operations not already defined in the library:

val m = USD(123.456)
val m2 = m.map(x => BigDecimal(x).setScale(m.currency.formatDecimals, BigDecimal.RoundingMode.HALF_EVEN).toDouble)

.. however, the Money type uses BigDecimal for the underlying amount. The map method works with the value field which is a Double. Therefore, applying map to a Money object could result in a loss of precision. Perhaps not a big deal when rounding, but other operations may be adversely affected.

I am looking at a way to create a Money.map that apply transformations directly to the BigDecimal.

[bytecodeguru]

In fact, these may be switched. I think toFormattedString should apply the rounding, but toString should not - it should include the fully precise value. Thoughts on this?

I have mixed feelings on this. For symmetry I'd like to see no loss of precision between Money.toString and Money.apply(s: String). And for the principle of least surprise I'd like to see the same amounts when printing with .toFormattedString and .toString, or at least document explicitly the intended different behaviour.

[garyKeorkunian]

@bytecodeguru Hmm? So, if there should be no loss of precision with toString and toFormattedString should be the same, doesn't that mean no rounding should be applied to either of these methods?

The idea behind toFormattedString is (or should have been) that the output is formatted to the standard of that currency, applying rounding as necessary. So ...

val m = USD(123.456)
m.toFormattedString // returns "$123.46"
m.toString // returns "123.456 USD"

[bytecodeguru]

You are right, and I think that we agree on this:

• .toString should not apply rounding.
• .toFormattedString should apply rounding and have a better documentation about its behaviour.

[bytecodeguru]

.. however, the Money type uses BigDecimal for the underlying amount. The map method works with the value field which is a Double. Therefore, applying map to a Money object could result in a loss of precision. Perhaps not a big deal when rounding, but other operations may be adversely affected.
I am looking at a way to create a Money.map that apply transformations directly to the BigDecimal.

The .map method imho is leaking an implementation detail. That's the reason I would still prefer to have a .rounded method. What is the current status of SQUIP 1?

[garyKeorkunian]

Yes, I agree a rounded method makes sense.

Some experimentation has been done around SQUIP 1, but nothing definitive yet. At best, that may find itself in a 2.x release as it would break binary compatibility.