I know no one asked for my opinion, but if you will indulge me
for a moment -- i think the most important concern is to keep the
type simple, minimal, and above all *immutable*.
Thus:
1. Prevent setting of attributes.
2. Turn 'precision' into a read-only attribute. To set precision,
just make a new number with decimal(x, new_precision).
3. But don't call it 'precision'. The word 'precision' usually
means either the total number of significant digits, or the
least significant distinguishable unit. What we're talking
about (number of digits after the decimal point) is neither.
I believe the correct term is 'scale' (from SQL). See also
http://www2.hursley.ibm.com/decimal/.
4. Get rid of copy(); it's unnecessary if you're immutable.
5. Get rid of 'frac()'. I don't see how it would be needed
very often, and it's easy to do x - long(x).
That leaves a simple immutable numeric type with no public methods
and just one attribute -- hence the least possible burden on a
future version of Python, if this type eventually becomes built-in.
(And the least possible burden is a good goal in general anyway.)
Also:
6. No global mutable state. That means no global settings for
default precision or rounding mode. Either pick a standard
precision or always require the second constructor argument.
Rounding mode is a tougher problem; i see two solutions:
(a) Eliminate variable rounding; always round half to even.
(b) Set rounding function as an attribute of the number.
Operators use the rounding function of the first operand.
This lets modules control module-local rounding behaviour
if they really want to do so, without interfering with
the rest of the program.
This may sound like a harsh requirement, but i am convinced that
global mutable settings will cause nightmares for people who try
to make their modules and programs interoperate.
* * *
I know the name is a relatively small issue, but my vote would be for
the type to be called either "fixpoint" or "decimal". The type name
should definitely be lowercase for something as basic as a number,
and also lowercase if it's to be a candidate for a future built-in.
Arguments for "fixpoint":
F1. Shorter than "fixedpoint". It's okay to drop "-ed", since
"floating point" -> "float" is accepted.
F2. "fix" alone is too unspecific.
F3. The important difference between "fixpoint" and "float" is that
the precision doesn't change.
F4. Already the name of some fixed-point number packages.
Arguments for "decimal":
D1. Simple, short, friendly.
D2. The important difference between "decimal" and "float" is that
the fractional part is decimal.
D3. Already the name of a SQL standard data type.
I think i am currently leaning toward "decimal", because D2 holds
a few microlitres more water than F3 for me.
-- ?!ng
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4