Toppling the numeric tower

[Bengt Richter]

On Thu, 26 Jul 2001 19:21:22 GMT, "Tim Hochberg" <tim.hochberg at ieee.org> wrote:
>
>"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:
>
I think that comes down to defining what you mean by exact. IMHO associating
inexactness with a particular representation type (and therefore with literals
traditionally implying that type) is a compromise that leads right to your
example following here.
>>>> 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.
>
Maybe << should not really be called an integer operation. I think it's really
a set operation, but if you wanted to use it with float-represented operands,
you could view
    x<<y
as shorthand for
    x*(2**Y)
so you get
    1e0*(2**2e0)
and go from there. But I think really it's an operation on a set of integers
which are the (unique) bit positions of ones in the integer you conventionally
think of as being shifted. In which case
    x<<y
means add y to every integer in the set x. Probably should be building a new set
composed of elements that are successors to the elements existing in the first set,
or something like that, but I'll leave it to the specialists to clean that up ;-)

I suspect that all the "bit-twiddling" operations really are better described
abstractly as set operations, not integer ones. There's just an easy familiar mapping
between the sets of this type and integers represented in typical binary.

Anyway, for x<<y as numeric expression x*(2**y) , I would call all the values in
the example exact, unless you want to define certain numeric literal syntax as having
the side effect of setting the exactness attribute to false. This example, IMO, should
return 4 # exact.

I also think 0.5<<2.0 ought to return an exact value, and 0.0<<0.5, but not 2.0<<0.5,
and not (1/3)<<2 unless there's rationals representation available.

OTOH, I really think the set interpretation is cleaner conceptually. You can write 
    1e0*(2**2e0)
if that's what you want, and leave << for bit sets. You could view integer
operand x of x<<y as being silently coerced to bit set and back. A bitset
would have a natural conversion to list or tuple. E.g.,  list(bitset(11)) => [0,1,3]

If 3.0 is going to have unified numerics, where float is mostly a hidden representation
detail, then linkage between the concept of inexact and float will be a wart to remove.
People will see inexact and think to themselves, oh, that's a float, and that will be
misleading their thoughts IMHO, even if it is true hidden implementation fact for most
implementations most of the time.