floating point in 2.0

[Bengt Richter]

On Fri, 8 Jun 2001 00:29:11 -0400, "Tim Peters" <tim.one at home.com>
wrote:
[...]
>Very good advice indeed.  What if they're accumulating in double instead?
>Without reliable access to double-extended, I'm afraid we're left with
>obscure transformations.  For most Python users, I expect decimal f.p. with
>user-settable precision is going to be much easier to use.
>
Perhaps too easy? ;-) I am not sure "user-settable precision" will be
clear enough a concept for most. Will they understand exactly what is
guaranteed by a given setting? Will you be able to explain it to them?

E.g., will the setting say how many fractional decimals to carry,
or how many significant digits in all? Will the implication be that
inputs are to be considered as having possible errors of +/- 0.5 times
a one in the least significant input digit position?

Should interval arithmetic be used to track the bounds of possible
errors through computation, and an optional exception be thrown if
output formatting demands more figures than are accurately available?
Or if an intermediate result becomes too imprecise?

How many appreciate the difference between probable errors in data
itself and errors in representation of data, and how the two are
transformed and intertwingled in algorithms?

Would (value,tolerance) be a more intuitive way to specify precision
(indirectly) than decimal precision in some cases?

Perhaps it would be useful to look at the problem in terms of actual
assertions one might like to be able to write concerning values and
their representations? E.g., something that says that printing
"10.0" after computing the sum of 100 ".100" values is (barely) ok,
but warns you that "10.0000" is illusory.

BTW, I had another little idea ;-) tying this into formatting of
objects: If class Quantity defined __str__ with an optional second
argument, then the % operator could pass the relevant slice of the
format string along with the object's "self" to the __str__ method
and you'd have open-ended formatting capability. E.g.,

	"%20.3.7s" % ( x,)

would make the effective call

	x.__str__('20.3.7')

to get the formatted representation. This example might be radix-7
printed 20 wide with 3 septimals(?). Or it could be 20 wide with
3 decimals verifying 7-digit precision of the representation. Or
anything you might like to encode between the '%' and 's'.

If you wanted to be able to pass about any control string, you
could allow a quoting delimiter like "%'special stuff's ..."
or maybe bracketing delimiters: "%[special stuff]s ..." etc.

(Please excuse if I am re-inventing a Python wheel. This seems
like one of those things you might already have done in some
form to handle formatting).