Don't use `BigFloat.exact` in repr output.
repr output for BigFloat objects should show the hex form of the float instead, since recreation is then unaffected by context. str can continue to show a decimal string.
At the same time, disable the use of BigFloat.exact for strings: it's misleading.
We need to support various cases:
- Conversion from a decimal string, hex string, integer or float to the current context, taking into account the current rounding mode. This operation is provided by the regular
BigFloatconstructor. - Context-independent conversion from a hex string with given precision in bits, as an inverse to the
reproperation. The precision is necessary, since it can't be inferred uniquely from the hex form of the output (unless we use a nonstandard normalization). This could be provided by theBigFloat.exactconstructor with aprecisionargument. - Context-independent conversion from a hex string, float, or int, inferring the number of bits necessary to do an exact conversion. (Could also be extended to those decimal strings that are exactly representable in binary, with an error for strings not exactly representation in binary.) This could be provided by the
BigFloat.exactconstructor without aprecisionargument.
Proposed behaviour:
- The output of repr should look like
BigFloat.exact('0x1234p+1', precision=53). - The
BigFloat.exactconstructor should always require a precision. - The
BigFloat.exactconstructor should only accept values for which an exact conversion (with the given precision) can be performed. That excludes most decimal strings, for example. - The regular
BigFloatconstructor always uses the current context, as before.
Do you even need exact? In gmpy2, mpfr currently accepts base and precision keywords. You could add an exact keyword that will raise an exception is the conversion is inexact. If no precision is specified, then try to determine a precision that is large enough to guarantee an exact conversion. (Ugly hack - I sort of do this already by associating a special meaning to precision=1. It works with float and integers but not hex strings.)
Moving this out of the 0.4.0 milestone.