Rethinking default BigDecimal behavior?

On Wed, Dec 14, 2011 at 11:15:25AM -0800, Derek Chen-Becker wrote:
> Could we revisit https://issues.scala-lang.org/browse/SI-1812? BigDecimal
> is a tool with sharp edges, but that doesn't mean we have to blunt it so
> that the uninformed don't cut themselves, does it? At the very least, if we
> have to have a dumbed down version, could it just be scala.math.Decimal and
> leave scala.math.BigDecimal with the same default behaviors as the Java
> class it purports to wrap?

I would support renaming Scala's BigDecimal to Decimal (to avoid
confusion), although I don't find Java's BigDecimal particularly
compelling. In my opinion, if you want Java's BigDecimal behavior you
can always just use that class directly.

I don't expect people will want scala.math to contain two different
decimal implementations, which is why I mention this. I consider
creating a good decimal implementation for Scala more important than
maintaining compatibility with java.math.BigDecimal.

I would be fine with scala not having its own BigDecimal and instead having some better Decimal implementation. Right now, though, it looks like a wrapper class but it imposes different behavior than one would expect coming from the Java version. Having said that, it would be nice to have a Scala wrapper for it, since Java APIs (JDBC, for example) use BigDecimal.
Derek

On Wed, Dec 14, 2011 at 10:31 PM, Derek Chen-Becker <dchenbecker@gmail.com> wrote:

I would be fine with scala not having its own BigDecimal and instead having some better Decimal implementation. Right now, though, it looks like a wrapper class but it imposes different behavior than one would expect coming from the Java version. Having said that, it would be nice to have a Scala wrapper for it, since Java APIs (JDBC, for example) use BigDecimal.

Create a SIP?

Cheers,
√
 

Derek

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

On Thu, Dec 15, 2011 at 5:15 AM, Derek Chen-Becker <dchenbecker@gmail.com> wrote:

Could we revisit https://issues.scala-lang.org/browse/SI-1812? BigDecimal is a tool with sharp edges, but that doesn't mean we have to blunt it so that the uninformed don't cut themselves, does it? At the very least, if we have to have a dumbed down version, could it just be scala.math.Decimal and leave scala.math.BigDecimal with the same default behaviors as the Java class it purports to wrap?

The default math context for an instance of BigDecimal can be changed with the apply() method. (This wasn't obvious to me originally.)
scala> BigDecimal(1) res0: scala.math.BigDecimal = 1
scala> res0 / 3res1: scala.math.BigDecimal = 0.3333333333333333333333333333333333
scala> res0.mc res3: java.math.MathContext = precision=34 roundingMode=HALF_EVEN
scala> res0(java.math.MathContext.UNLIMITED)res4: scala.math.BigDecimal = 1
scala> res4 / 3java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
scala> res4.mc res5: java.math.MathContext = precision=0 roundingMode=HALF_UP
-jason

Right, I know that I can change it, what's troubling me is that the default MathContext differs from the Java class that it wraps. I actually stumbled onto this because the ScalaCheck Arbitrary.arbBigDecimal started throwing ArithmeticExceptions that made the checks terminate prematurely. Now that I know that the behavior differs I can just work around it by being explicit about my MathContext, but for someone coming from the Java world there's nothing in the scaladocs mentioning the change and I'm not convinced that trading one runtime exception (Paul's example was for division) for another (construction/wrapping) is a worthwhile tradeoff:
scala> BigDecimal(MyJavaAPI.getMeABigNumber)java.lang.ArithmeticException: Division impossible at java.math.BigDecimal.divideToIntegralValue(BigDecimal.java:1783) at java.math.BigDecimal.divideAndRemainder(BigDecimal.java:1916)        ...