[Python-Dev] Revamping Python's Numeric Model
Guido van Rossum
Mon, 06 Nov 2000 12:49:35 -0500
> > That's your choice. Wildly inaccurate is sometimes unavoidable. This
> > is clearly an issue open for debate, but note that I speak from
> > experience: ABC used rationals unless you forced it to use reals, and
> > the rationals *did* cause real users to complain about how slow ABC
> > was.
> Well, experiences differ. I'm on the Scheme48 (which uses rationals) mailing
> list, and nobody ever complained. Besides, if "forcing" is simply saying
> either inexact() (and note that inexact-exact operations are performed
> inexactly) or mixing in an inexact literal (assuming that's what 1.0 will
> be), it might be easier. I don't know ABC well enough to say how the
> forcing mechanism worked.
Scheme has no real users -- only CS types. :-)
ABC's forcing was as simple as writing ~x or mixing inexact numbers.
We did have the notion that 1.0 was an exact literal (to me it looks
exact!) so maybe that was an additional problem.
> > I think this deserves very explicit mention in your PEP. An example
> > of how I would go about implementing my own Rational class or
> > extension type would help.
> Well, I don't see why there should be a difference from what happens
> currently. The thing is, the model will not support you telling it
> at runtime what the results for operations on types it already knows
> should be: that would make us Scheme, not Python.
Agreed. I think what makes me feel uneasy is that your proposal
assumes that there is One True Numeric Type, and all the rest are
second-class numbers. Python currently makes no such claim: there are
many numeric types built in and you can add your own types that play
along. The only thing that makes a difference is that there are
literals for the built-in types and not for the extension types; but
apart from that they have all the same privileges, and the coercion
rules work in everybody's favor (except when they don't :-). Placing
more emphasis on One True Numeric Type runs a risk of discriminating
against the others.
> > Also, the coercions PEP is still in need of an author. Maybe you want
> > to take this on too? It will help your numeric proposal if you can
> > write down how you think coercions should work.
> Smooth, real smooth. OK, sold to the highest bidder -- I take it.
> I'll update it and 0000, and start reading MAL's pages.
OK, it's a deal. But make yourself a co-author with MAL.
--Guido van Rossum (home page: http://www.python.org/~guido/)