[Python-ideas] Python Numbers as Human Concept Decimal System

Oscar Benjamin oscar.j.benjamin at gmail.com
Tue Mar 11 15:40:09 CET 2014


On 11 March 2014 13:30, Antoine Pitrou <solipsis at pitrou.net> 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-java

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.


Oscar


More information about the Python-ideas mailing list