prePEP: Decimal data type

[Steve Williams]

John Roth wrote:
[snkip]

Part of the reason why COBOL has the separate operators
is that the *destination* of the operation specifies how the
result is computed. You can't do that with intermediate
results if you use expression notation.

Ah well, it's Saturday night, I've had a glass of wine, and so I post on
comp.lang.python.

Assert: Bob Bemer's PICTURE clause (supremely platform independent) is
the dreaded static data type.

You can write 1000 lines of COBOL arithmetic using + - * / and get
consistent results based on the PICTURE of the target and the ROUNDED
clause.

You can even sit down with the end user (she who is uninformed as to the
wonders of real analysis, but who holds your career in her hands) and
discuss and markup the program listing. Even if she doesn't know the
difference between / and //.

Moreover, most COBOL compilers accept any PICTURE clause as a source. Viz:

03 Amount Pic $$$,$$$,$$9.99

Compute Amount = Units * Unit-Cost

Compute Total-Amount = Total-Amount + Amount

Divide Days into Amount Giving Amounts-Per-Day Rounded

You want precision? Voila: Pic $,$$$,$$$,$$9.9999.

(Forgive me, computer scientists, for the use of the nasty verbs--that's
just COBOL).

Instead, we discuss separate operations for integers, rationals, reals,
complex, quaternions, octionions and 'money'--"To infinity and beyond."

I've written Python functions where I pass in a target picture along
with operands. But then it was on Saturday night, and I had a glass of
wine.

 

[Aahz]

if otherType is an int or long:

a. an exception is raised
b. otherType is converted to Decimal
c. Decimal is converted to int or long (with ``int()`` or
``long()``)

otherType is converted to Decimal unless precision in the current
Context would be exceeded; in that case you raise ValueError.

if otherType is a float:

d. an exception is raised
e. otherType is converted to Decimal (rounding? see next item in
discussion)
f. Decimal is converted to float (with ``float()``)

Raise an exception. Because of the precision issues in floating point,
conversion to Decimal must always be explicit.

if otherType is a string:

g. an exception is raised
h. otherType is converted to Decimal
i. Decimal is converted to string (bizarre, huh?)

Exception is raised, just as with all other uses of strings and numbers.

When passing floating point to the constructor, what should happen?

j. ``Decimal(1.1) == Decimal('1.1')``
k. ``Decimal(1.1) ==
Decimal('110000000000000008881784197001252...e-51')``

That's tough. I'm inclined toward requiring an explicit conversion
through a function call that isn't the Decimal constructor, but ease of
use is also a factor.

2. The value could be of the type:

- another Decimal
- int or long
- float
- string

Also a tuple of int/longs.

4. The Context must be omnipresent, meaning that changes to it affects all
the current and future Decimal instances.

Here's the tricky part (and where I abandoned work): the Context must be
thread-local. Also, Context applies only to operations, not to Decimal
instances; changing the Context does not affect existing instances if
there are no operations on them.

15. To be immutable.

This is why the Context can't affect existing instances. ;-)