Against PEP 240

Bruce Sass bsass at freenet.edmonton.ab.ca
Thu May 31 16:14:08 EDT 2001


On Thu, 31 May 2001, Nick Perkins wrote:
<...>
> The current system never bothered me because I was used to floats before
> coming to Python, and did not suffer the 'surprise' in question.

I don't think they would surprise anyone who understood binary
representation... and any book/teacher not getting into binary before
they get into binary-fp needs a slap-upside-the-head (geez, I sure
hope Mr. Martelli wasn't the primary educator of those confused
pupils :).

You don't teach science without teaching chemistry, 'cause, "What in
the world isn't chemistry?"... What in computing isn't binary.

> At this point in the discussion, I am more interested in the distinction
> between a Decimal type and a Rational type.
>
> BTW, I have seen the term BCD thrown around, (Binary Coded Decimal)...
> Years ago I learned about BCD being a system that codes 2 decimal digits per
> byte.
> Is this still what is meant by BCD?

Yup.  "packed BCD", actually.

> I would think that a modern 'Decimal' type would not use this, but something
> more like base*10^exp, where base and exp are stored as binary integers.

That seems like a lot of work compared to: a + b + 6
i.e., a BCD addition == binary (addition + 6)

Old microprocessor, pre-FPU days, either had a decimal mode (e.g.,
6502 with SED, set decimal mode), or an explicit instruction to do the
adjustment (e.g., Z80 with DAA, decimal adjust accumulator)...
this is not new technology, as Tim Peters pointed out...

...although I'm more likely to blame marketing and corporate greed
than the designers.

<...>
> Basically, I can't seem to make up my mind on this issue.
> I do, in principle agree with Alex's mantra: " 7.35 should mean 7.35 ".
> (on the other hand)...
> Modern CPU-FPU operations are going to be way faster than any other system:
> what about newbies wondering "why are my calculations so slow?"

Ya, ditto, mostly.

I don't really care about the mewbies, those willing to learn will
figure it out.  The default should be `whatever works best', with an
explicit identifier required if your code is relying on properties of
a particular type of numerical representation; and maybe a way to
specify how unadorned numbers should be treated, with a way to
override the default on a case by case basis [oh ya, tha'd go over
well :].


- Bruce





More information about the Python-list mailing list