On Thu, 15 Oct 2020 at 04:22, Guido van Rossum <gu...@python.org> wrote:
>
> This all seems a pretty artificial argument.
>
> In plain English, "1/3" is not exactly representable in decimal form, but
> something like 0.1111111111111111111111111111 * 0.22222222222222222222222222
> *is* (assuming the inputs are what they appear).
>
> Since the spec clearly means to say "exactly representable in the (current or
> given) context's precision" that phrase (or something non-empty like it)
> should just be added to the docs and the argument is over.
Maybe the argument isn't productive but I think that there is a
reasonable feature request in this.
The decimal module currently has a way to trap whenever something
inexact occurs e.g.:
>>> from decimal import *
>>> getcontext().traps[Inexact] = True
>>> Decimal('1') / Decimal('3')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
decimal.Inexact: [<class 'decimal.Inexact'>]
That's useful for ensuring that a calculation cannot silently
propagate rounding errors: if it succeeds the result is exact.
In the case of 1/3 no finite level of precision can give an exact
result but in other cases it is possible that increasing the precision
would:
>>> d = Decimal('1' * 20)
>>> d*d
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
decimal.Inexact: [<class 'decimal.Inexact'>]
>>> getcontext().prec = 50
>>> d*d
Decimal('123456790123456790120987654320987654321')
The useful feature that is not available from the decimal module is a
way to say: use enough digits to give an exact result if at all
possible but otherwise raise an error (or perhaps round the result
depending on traps).
There are a couple of obvious strategies for trying to find that
number of digits that have been suggested above in this thread. One
approach is to trap the inexact flag and increase the precision if
needed:
while True:
try:
calculation()
except Inexact:
getcontext().prec *= 2
The problem is that for something like 1/3 this is an infinite loop
that will consume all the memory in the machine. Hopefully you'll get
something like MemoryError but this can also just bork everything. Of
course we can put limits on the loop but we don't actually need a high
precision to conclude that an exact division will not be possible in
the case of 1/3.
Another approach is just to use the maximum precision specified by the
module but that also leads to possible borkage:
>>> getcontext().prec = MAX_PREC
>>> Decimal('1') / Decimal('3')
Python(74959,0x10b4cd5c0) malloc: can't allocate region
*** mach_vm_map(size=421052631578947584) failed (error code=3)
Python(74959,0x10b4cd5c0) malloc: *** set a breakpoint in
malloc_error_break to debug
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
MemoryError
A better approach is to think carefully about each individual
operation and bound the number of digits that could be needed for any
possible exact result:
from decimal import *
def exact_divide(a, b):
num_digits = lambda d: len(d.as_tuple().digits)
digits_bound = num_digits(a) + 4 * num_digits(b)
ctx = getcontext().copy()
ctx.traps[Inexact] = True
ctx.prec = digits_bound
return ctx.divide(a, b)
I haven't thought too hard about corner cases but I think that
something like num_digits(a) + 4 * num_digits(b) bounds the possible
number of digits for any possible exact a/b. After cancelling the gcd
of the mantissas we can only divide exactly by 2, 5 or some
combination of those. Each factor of 2 or 5 in the divisor requires
one extra digit so the worst case is dividing by a power of 2 and
10**n < (2**4)**n. So I think the number of extra digits needed is no
more than 4 times the number of digits in the divisor. That gives:
>>> exact_divide(Decimal(1), Decimal(8))
Decimal('0.125')
>>> a = 123456789 ** 10
>>> exact_divide(Decimal(a**2), Decimal(a))
Decimal('822526259147102579504761143661535547764137892295514168093701699676416207799736601')
>>> exact_divide(Decimal(1), Decimal(3))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "asd.py", line 10, in exact_divide
return ctx.divide(a, b)
decimal.Inexact: [<class 'decimal.Inexact'>]
Of course some of these operations could lead to a lot of memory usage like
exact_add(Decimal('1e10000000000000'), Decimal('1'))
but there can also be ways to limit the maximum precision that can be
used by exact_add without requiring the working precision itself to be
at that level for *everything* (including 1/3).
The standards on which the decimal module is based do not require that
there be functions for doing this as they are based on the idea that
the precision is not necessarily configurable. Python's implementation
does provide configurable precision though and also makes it possible
to represent an individual decimal object with any number of digits
regardless of the active context.
It would be useful in some cases to have functions in the decimal
module for performing exact-if-possible operations like this.
Potentially it could make sense as a special context although I don't
know how easy it would be to implement like that.
Also an obvious missing feature is the ability to convert from
Fraction to Decimal exactly (when the result can be exact but raising
otherwise). In that case we pretty much know that if the Fraction can
be represented within the constraints of memory then any corresponding
exact Decimal can be as well. The reverse is not the case even though
it is possible to convert exactly from Decimal to Fraction:
>>> Fraction(Decimal('1e100000000000')) # this is dangerous
^C
--
Oscar
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VOT4SW2MMNFFC6GAF5TIRQ7ZEWJG7HH3/
Code of Conduct: http://python.org/psf/codeofconduct/
