Add support for extracting precision from strings

2003-07-23T22:00:06Z

Attached is a patch to extract the initial fixed point
precision from numbers in string form. Two interesting
issues arose during this development:

For fixed point strings extracting precision is
straight forward, but for strings in scientific
notation it is a little awkward. This is because
precision means something different in these two
notations. In scientific notation precision relates to
the accuracy of the entire number and an error estimate
is implied by the number of significant digits. Fixed
point numbers however are exactly accurate and their
precision has no bering on their accuracy. When
converting from scientific notation to fixed point,
fixedpoint.py now captures the entire accuracy of a
number in scientific notation.

Prior to patch:
>>> print FixedPoint("12.3e4")
123000.0
>>> print FixedPoint("12.3456e-4")
0.00
>>>

After patch:
>>> print FixedPoint("12.3e4")
123000.0
>>> print FixedPoint("12.3456e-4")
0.00123456
>>> print FixedPoint("12.3456e-4", 2)
0.00
>>>

The second issue concerns backwards compatibility.
Prior to this patch it was assumed that the default
behavior of str(FixedPoint("45.678")) should be to
return "45.68". This is useful for conversions where
the system always uses hundredths of some marker value.
But it is not obvious behavior for any other use (e.g.
parsing stock market prices or scientific data). Since
fixedpoint.py has not yet been accepted into the main
Python body I propose that we deal with this
compatability problem now. Uses of fixedpoint.py that
require a specific fixed point precision need to
explicitly declare that precision at the point of
conversion instead of relying on the default value.
Otherwise we will never be able to change the default
value.

This patch is NOT backwards compatible - it changes the
default behavior for str(FixedPoint("45.678")). I
leave it up to the collective to decide the "one
obvious" way for fixedpoint.py to behave and what
mechanism should be used to change (and disable) the
default precision *on the fly*. If you are using
fixedpoint.py in a project that assumes the old
behavior and want to upgrade, add ", 2" to each place a
string is converted to a fixed point number, or make an
explicit call to x.set_precision(2) for each fixed
point value that came from a string.

Duane

Full python2.1 support

2003-07-09T10:23:47Z

Hi,

Despite what is said in v0.1.1's README, it does not
work with python2.1
(most of the tests fails)

There are two problems mainly:

- property() does not exists, so precision=None,
however this is not the desired behaviour,

- type(an_instance) returns types.InstanceType and is
not callable (different from py2.2 new style classes
whose type in the class itself)

You'll find here a patch fixing these problems.

Best regards,

-- Sébastien Bigaret <sbigaret@users.sourceforge.net>

Doc changes

2003-02-15T22:04:16Z

This started by repairing the explanation of rounding.
That turned out to be a small part of it in the end.
Most of it is simply reflowing paragraphs to squash
long lines (if this becomes part of the std library docs,
Fred will be unhappy if any line spills beyond column
76 or so).

Recent changes to patches

Add support for extracting precision from strings

Full python2.1 support

Doc changes