Clean Singleton Docstrings

Steven D'Aprano steve at pearwood.info
Sat Jul 16 05:46:34 EDT 2016


Oh, and a further thought... 


On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:

> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
> exact ones with a flag set to mark them as inexact.)

But that's *wrong*. Numbers are never inexact. (You can have interval
arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
calculations which are exact or inexact, not numbers. There's no a priori
reason to expect that 0.499999 is "inexact" while 0.5 is "exact", you need
to know the calculation that generated it:

py> from decimal import *
py> getcontext().prec = 6
py> Decimal("9.000002")/6  # inexact
Decimal('1.50000')
py> Decimal(1)/2 - Decimal('1e-6')  # exact
Decimal('0.499999')


It seems to me that unless you're prepared to actually do some sort of error
tracking, just having an "inexact/exact" flag is pretty useless. If I
perform a series of calculations, and get 1.0 as the result, and the
inexact flag is set, that doesn't mean that 1.0 is the wrong answer -- it
may be that the errors have cancelled and 1.0 is the exact answer. Or it
may be that the error bound is 1.0 ± 10000, and the calculation has
diverged so far from the correct result that it is useless.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.




More information about the Python-list mailing list