On Wed, Oct 14, 2020 at 03:33:22PM -0400, Random832 wrote:

That is nonsense. "exactly representable" is a plain english phrase and has a clear meaning that only involves the actual data format, not the context.

Perhaps your understanding of plain English is radically different from mine, but I don't understand how that can be.

The actual data format has some humongeous limits (which may or may not be reachable in practice, due to memory constraints). It is obvious to me that "exactly representable" must take into account the current context:

- If it didn't, then the context precision would be meaningless; changing it wouldn't actually change the precision of calculations.

- Decimal(1)/3 is Decimal('0.3333333333333333333333333333') by default, a mere 28 digits, not MAX_PREC (999999999999999999) digits.

Nonsense. The meaning of the inexact flag means that the module *chose* to discard some information.

Is it truly a choice, if the module has no choice? Do you expect the decimal module to return an exact result for 1/3 or sqrt(2)?

I think that you are just surprised that decimal rounds operations to the current context, not to the implied precision of the operands. My guess is that you were expecting arithmetic on operands to honour their precision:

getcontext().prec = 3 Decimal('0.111111111111') + Decimal('0.222222') # expect Decimal('0.333333111111') # but get Decimal('0.333')

but (aside from "wishful thinking") I can't see why you expected that.

(To be honest, I was surprised to learn that the context precision is ignored when creating a Decimal from a string. I still find it a bit odd that if I set the precision to 3, I can still create a Decimal with twelve digits.)