Rethinking default BigDecimal behavior?

[Derek Chen-Becker]

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?

Thanks,

Derek

[Erik Osheim]

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.

-- Erik

[Derek Chen-Becker]

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

[√iktor Ҡlang]

On Wed, Dec 14, 2011 at 10:31 PM, Derek Chen-Becker <dchen...@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 Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Jason Zaugg]

On Thu, Dec 15, 2011 at 5:15 AM, Derek Chen-Becker <dchen...@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 / 3

res1: 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 / 3

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.

scala> res4.mc

res5: java.math.MathContext = precision=0 roundingMode=HALF_UP

-jason

[Derek Chen-Becker]

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)

        ...