floating point in 2.0

[Tim Peters]

[Tim]
>> For most Python users, I expect decimal f.p. with user-settable
>> precision is going to be much easier to use.

[Bengt Richter]
> 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?
> ...
> [followed by 1, 2, 3, 4, 5, 6, 7, ... at least 8 similarly open-ended
>  questions]

The working model for decimal f.p. (which Aahz is implementing) is IBM's
Decimal Arithmetic Proposal, at

    http://www2.hursley.ibm.com/decimal/

It's been used successfully in REXX for close to 20 years, so it's not that
big a gamble.

Brief replies to selected questions:

> ...
> 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?

No, interval arithmetic is an expert's tool; the error bounds mushroom out
of usefulness in a non-expert's hands.

> 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?

Among newbies, virtually none.

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

Sure, but not for newbies.  Among experts, some will want tolerance to be in
a +- absolute value sense, some in a +- relative error sense, others in a
standard deviation sense.  The goal of decimal f.p. is to make life easier
for newbies -- experts can go fight with each other and leave the newbies in
peace <wink>.

> 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.

IBM's proposal incorporates a notion of "significant" trailing zeroes, in a
related sense.

> 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'.

We're losing focus here, Bengt <wink>.  May be an interesting PEP here, if
you're motivated enough to pursue it!

> 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).

No, on the few occassions I've seen "stuff like this" done, people use a
plain %s format code and give explicitly-called format methods to their
objects; e.g.,

    "%s" % x.format(20, 3, 7)

vs

    "%20.3.7s" % x

Especially when format parameters can vary dynamically, it's more convenient
and clearer to have a call-form than to paste together a format control
string at runtime.  For example,

>>> from Rational import Rat, Format
>>> x = Rat.Rat("1/7")
>>> print x.str(base=7)
1/10_7
>>> print x.str(base=7, mode=Format.FIXED, prec=3)
0.100_7
>>> print x.str(base=10, mode=Format.FIXED, prec=40)
0.1428571428571428571428571428571428571429-<h
>>> print x.str(base=32, mode=Format.FIXED, prec=10)
0.4i94i94i95_32-<h
>>> print x.str(base=32, mode=Format.FIXED, prec=10, use_letters=0)
0.4(18)94(18)94(18)95_32-<h
>>>

Etc.  There are other possible keyword arguments not shown above, and it
would be take me a year just to *define* a control-string format I could
remember how to use <wink>.  Packaging common combinations for easy reuse
can be done in different ways; e.g., continuing the last example,

>>> f = Format.Format(base=32, mode=Format.FIXED, prec=10, use_letters=0)
>>> print x.str(f)
0.4(18)94(18)94(18)95_32-<h
>>>

like-regexps-%-is-most-satisfying-in-simple-cases-ly y'rs  - tim