On 11 March 2014 13:30, Antoine Pitrou firstname.lastname@example.org wrote:
Le 11/03/2014 11:51, Oscar Benjamin a écrit : >
The decimal.Decimal type is IMO overly complex and should really be for niche use-cases like other non-stdlib multi-precision numeric types.
What is complex about it? The notion of a decimal's precision in number of digits is understandable by a 10 year old.
I agree, that's why I say that we just have a type with a fixed maximum number of digits. I think lots of people will be able to understand that.
It is arguably much simpler than unicode and character encodings. Besides, for most applications Decimal's current precision will be good enough: changing the current context (which, I believe, is thread-local, not process-global) is only necessary in special cases.
The problem is that the context cannot be depended upon so the result of trivial calculations or even a negative decimal literal will depend on something that can be changed anywhere else in the code. The expression -1.123456789d will evaluate differently depending on the context and I think many people will be surprised by that. I expect that this would lead to naive code that breaks when the context is changed. Great care needs to be taken to get this right, or otherwise it should just be considered generally unsafe to change the context.
Java's BigDecimal is more user friendly in some important ways. It performs all calculations exactly until you explicitly round.
So if call BigDecimal(2).sqrt(), I get an infinite precision BigDecimal? :-)
(or perhaps it doesn't have .sqrt()?)
Apparently it does not: http://stackoverflow.com/questions/13649703/square-root-of-bigdecimal-in-jav...
But let's take something similar: BigDecimal(1).divide(BigDecimal(3)). This expression cannot be computed exactly in decimal format so it raises ArithmeticError. If you want it to round to some precision then you can provide a context with BigDecimal(1).divide(BigDecimal(3), mymathcontext). This rounds as specified in mymathcontext and the result of the expression is not affected by someone else changing a global arithmetic context.