On 8/2/07, Terry Reedy <[EMAIL PROTECTED]> wrote: > "Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > | 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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
