Open mdickinson opened 10 years ago
At the same time, disable the use of BigFloat.exact
for strings: it's misleading.
We need to support various cases:
BigFloat
constructor.repr
operation. 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 the BigFloat.exact
constructor with a precision
argument.BigFloat.exact
constructor without a precision
argument.Proposed behaviour:
BigFloat.exact('0x1234p+1', precision=53)
.BigFloat.exact
constructor should always require a precision.BigFloat.exact
constructor should only accept values for which an exact conversion (with the given precision) can be performed. That excludes most decimal strings, for example.BigFloat
constructor 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.
repr
output forBigFloat
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.