HELP: restore my faith in Python

[Charles Hixson]

Wait.  The first suggestion was for a fixed precision class, which I think is a
great idea.  But now this seems to be being changed to a money class, which I
find much less worthwhile.  I suppose that it could be both decimal and fixed
precision, no real problem, but this seems to be drifting toward the idea that
it should only be used for money.
When I first heard "Fixed Precision" my interpretation was something like "ok,
we specify a max, a min, and a delta when we define something like this"
(granted, given that python variables aren't declared I haven't thought through
all of the options, still...).
There are lots of things that shouldn't be subjected to floating point
rounding.  Money is only one of them.  I rarely need to count things by three's
, but there are times when it would be convenient to work in sevenths of a week,
or 60ths of an hour.  (Standard time values won't work because this isn't a
date, but rather the number of minutes elapsed since a particular time, and the
elapsed amount of time can exceed 24 hours.)

One might consider having numeric classes that were flexible enough to handle
all of the standard units, and to manage conversions between them.  I'm not
really sure that this is reasonable, but it sure could help avoid some
problems.  And if it automatically knew whether you were talking about degrees
or radians (or mils?) trig calculations would be a lot easier.

I don't feel that I am actually drifting from the main point, though I may have
extended it a bit.  But I feel that this kind of extension should be taken
account of when the original design is made.  (Of course, one reasonable answer
is:  "That would make things too complicated.")

Johann Hibschman wrote:

> Ken Seehof writes:
> > Johann Hibschman wrote:
>
> >> More seriously, would this whole little discussion be a good reason to
> >> put a fixed-precision decimal class into the standard library?  A lot
> >> of people want to use floats for money, which is a fairly poor idea
> >> unless you know what you're doing.
>
> > Yes, but still dangerous, since people (who don't know what they aredoing)
> > will be converting from float to fpd, which will once again bring
> > back all the rounding problems (unless they remember to add epsilon).
>
> Not really.  That conversion would be under the control of the fpd
> class, which would have a defined precision, and therefore know
> exactly how to round the float.
>
> You'd need rules to multiply things with different numbers of decimal
> places, or (probably better), you could just call it an error and
> provide rounding methods.  Just don't mess with floats.
>
> --
> Johann Hibschman                           johann at physics.berkeley.edu