[Python-Dev] Unifying Long Integers and Integers: baseint
Gareth McCaughan
gmccaughan at synaptics-uk.com
Tue Aug 10 16:21:55 CEST 2004
On Tuesday 2004-08-10 14:35, Skip Montanaro wrote:
>
> >> I think it would be worth considering all the numeric types at once
> >> and come up with a reasonable hierarchy that includes float, complex
> >> and decimal types as well. (It's clear there is no "best" way to do
> >> that.)
>
> Dmitry> Something like following?
>
> Dmitry> object
> Dmitry> numeric
> Dmitry> integer
> Dmitry> int
> Dmitry> long
> Dmitry> float
> Dmitry> complex
>
> At some level it seems that float is a specialization of complex (w/ imag
> field == 0). Also, it's not clear that float or complex don't have
> something other than a sibling relationship to integers.
Start by thinking about the mathematical types, which have
nice clear subset relationships between them:
number
complex
real
integer
Python doesn't have anything between "number" and "complex" and
there's no particular reason to think it ever will, so let's
simplify:
number
real
integer
Now consider the different implementation types and fit them
in:
number
complex
real
(Decimal)
float
integer
int
long
I've reintroduced "complex" here as a name for the implementation
type, which in some sense should really be called complex_float
or something like that.
By way of clarification of the principles here, this is what
would happen to the hierarchy if Python were to acquire a
type for ratios of integers. I'll call that type "fraction"
and the underlying mathematical type "rational". Then we'd
get:
number
complex
real
(Decimal)
float
rational
fraction
integer
int
long
(You could argue that floats are rationals really, but that's
misleading even though it's true. The *structure* of arithmetic
operations on floats isn't the same as that on rationals.)
--
g
More information about the Python-Dev
mailing list