Toppling the numeric tower

[Tim Hochberg]

"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:
[SNIP]
> > 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
> types...
>
> 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
  or
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().

-tim