[Python-3000] Updated and simplified PEP 3141: A Type Hierarchyfor Numbers

[Jeffrey Yasskin]

On 8/2/07, Terry Reedy <tjreedy at udel.edu> wrote:
> "Jeffrey Yasskin" <jyasskin at gmail.com> wrote in message
> news:5d44f72f0708021153u7ea1f443jfdee3c167b011011 at mail.gmail.com...
>
> |        def __bool__(self):
> |            """True if self != 0."""
> |            return self != 0
>
> Could this be a Number rather than Complex method?

Yes, as could probably __add__, __sub__, __mul__, __abs__, and maybe a
few others, but I didn't have a good criterion for distinguishing.
What's fundamental about a "number"? I chose to punt for now, thinking
that we can move operations up there later if we want.

Remember that this is all duck typed anyway: if you overload a
function based on Number vs Sequence, that doesn't stop you from
dividing the numbers you got.

> ---------------
>
> | There is no built-in rational type
>
> Floats constitute a bit-size bounded (like ints) set of rationals with
> denominators restricted to powers of two.  Decimal literals and Decimals
> constitute a memory bounded (like longs) set of rationals with denominators
> instead restricted to powers of ten.

You are strictly correct, but I think people think of them as
approximations to the real numbers, rather than restricted and inexact
rationals. In particular, functions like exp, sin, etc. make sense on
approximated reals, but not on rationals.

> Math.frexp returns a disguised form of (numerator,denominator) (without
> common factor of two removal).  If undisguised functions were added (and
> the same for Decimal), there would be no need, really, for class Real.
>
> If such were done, a .num_denom() method either supplementing or replacing
> .numerator() and .denominator() and returning (num, denom) would have the
> same efficiency justification of int.divmod.
>
> I would like to see a conforming Rat.py class with unrestricted
> denominators.
> --------------------
>
> | And finally integers::
> |
> |    class Integral(Rational):
> |        """Integral adds a conversion to int and the bit-string
> operations."""
>
> The bit-string operations are not 'integer' operations.  Rather they are
> 'integers represented as powers of two' operations.  While << and >> can be
> interpreted (and implemented) as * and //, the other four are genernally
> meaningless for other representations, such as prime factorization or
> fibonacci base.  The Lib Ref agrees:
>    3.4.1 Bit-string Operations on Integer Types
>    Plain and long integer types support additional operations that make
> sense
>    only for bit-strings
> Other integer types should not have to support them to call themselves
> Integral.  So I think at least |, ^, &, and ~ should be removed from
> Integral and put in a subclass thereof.  Possible names are Pow2Int or
> BitStringInt or BitIntegral.

If some more people agree that they want to write integral types that
aren't based on powers of 2 (but with operations like addition that a
prime factorization representation wouldn't support), I wouldn't
object to pulling those operators out of Integral.

Then recall that Integral only needs to be in the standard library so
that the std lib's type checks can check for it rather than int. Are
there any type checks in the standard library that are looking for the
bit-string operations? Can BitString go elsewhere until it's proven
its worth?

> -----------
>
> In short, having read up to the beginning of Exact vs. Inexact Classes, my
> suggestion is to delete the unrealizable 'real' class and add an easily
> realizable non-bit-string integer class.

There are a couple of representations of non-rational subsets of the
reals from the algebraic numbers all the way up to computable reals
represented by Cauchy sequences.
http://darcs.haskell.org/numericprelude/docs/html/index.html has a
couple of these. I think RootSet and PowerSeries are the most concrete
there.

-- 
Namasté,
Jeffrey Yasskin