This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Rethinking default BigDecimal behavior?

5 replies
Derek Chen-Becker 3
Joined: 2011-12-14,
User offline. Last seen 42 years 45 weeks ago.
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
d_m
Joined: 2010-11-11,
User offline. Last seen 35 weeks 2 days ago.
Re: 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.

Derek Chen-Becker 3
Joined: 2011-12-14,
User offline. Last seen 42 years 45 weeks ago.
Re: Rethinking default BigDecimal behavior?
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
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Rethinking default BigDecimal behavior?


On Wed, Dec 14, 2011 at 10:31 PM, Derek Chen-Becker <dchenbecker [at] gmail [dot] 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
Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: Rethinking default BigDecimal behavior?
On Thu, Dec 15, 2011 at 5:15 AM, Derek Chen-Becker <dchenbecker [at] gmail [dot] 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

Derek Chen-Becker 3
Joined: 2011-12-14,
User offline. Last seen 42 years 45 weeks ago.
Re: Rethinking default BigDecimal behavior?
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)        ...

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland