Toppling the numeric tower
tim.hochberg at ieee.org
Thu Jul 26 21:21:22 CEST 2001
"David Eppstein" <eppstein at ics.uci.edu> wrote in message
news:eppstein-749F84.08434526072001 at news.service.uci.edu...
> In article <DLW77.49367$Cy.6275542 at news1.rdc1.az.home.com>,
> "Tim Hochberg" <tim.hochberg at ieee.org> wrote:
> > I would strip this down to
> > A. iscomplex()
> > B. isexact()
> > C. isintegral()
> I have to say that this would be more convenient for situations such as
> defining your own extension of number types for, say, exact arithmetic in
> Q[sqrt(3)]. Or even better Q[sqrt(-3)]. I was wishing I was able to do
> this recently for a different project unrelated to Python, unfortunately
> the program I was using didn't make it easy to plug in your own number
> But a couple points of clarification:
> (1) is it safe to assume that isintegral() implies isexact()?
Probably. Numbers that return true for from isintegral() should be usable
anywhere that Python integers are used today. In particular, if a and b are
integral in this sense then a & b, a ^ b, a | b, a << b, a >> b and
sequence[a] should all work. One could allow numbers that are have integral
values but are not exact (e.g., 1e0, 2e0, etc) to be used in these
circumstances, but consider the following:
>>> 1e0 << 2e0
4 # exact
4e0 # inexact
Either answer sucks: the first turns two inexact operands into an exact
result, while the second represents the results of bit twiddling, a discrete
operation if ever there was one, as an inexact, floating point number. The
best choice is to insist on exact numbers for integer operations.
Note that I don't know that this is the meaning for isintegral meant by PEP
228, but it is the one that makes sense to me.
> (2) should isintegral() return true for algebraic integers that are not
> rational integers?
No, for the reasons I've given above.
It may be that there is a better way to spell isintegral that makes it clear
that it means isusablewhereoldpythonintswereusable().
More information about the Python-list