On Dec 15, 2:00 pm, Lie <[EMAIL PROTECTED]> wrote: > I'm very surprised actually, to see that Python rejected the use of > fractional/rational numbers. However, when I read the PEP, I know > exactly why the proposal was rejected: People compared fractions with > integers, while it should be more fairly compared to floats.
Pretty lame reasoning, isn't it? I use the rationals from the gmpy module very successfully. All these arguments that follow are just silly. > > Arguments against: > - When I use the result of / as a sequence index, it's usually an > error which should not be hidden by making the program working for > some data, since it will break for other data. > ----> In Python 3 (and 2 w/ __future__), the / operator would always > return floats, and floats is invalid as sequence index, even if the > value of the float is whole. Since fractions is created with the / > operator on two integers, the behavior of fractions should mimics > float. So putting fractional type as sequence index should always be > considered as error (exception), a behavior consistent with floats. > Thus, the arguments specified above has turned invalid, at least in > Python 3. > - (this assumes the same type for them:) Int is a good type in itself, > not to be mixed with rationals. The fact that something is an integer > should be expressible as a statement about its type. Many operations > require ints and don't accept rationals. It's natural to think about > them as about different types. > ----> I agree, ints shouldn't be mixed with rationals. But floats > could. This argument is the main reason why I said most people > compared rational with integers. Many operations that requires ints > and don't accept rationals also don't accept floats. > > Other arguments: > - Slow: Doing addition and subtraction in fractions sure is expensive, > but doing division (the heaviest arithmetic operation) is extremely > fast in fractional numbers compared to in floating numbers. It is > clear that doing two integer multiplication and switching numerator- > denominator is much faster than doing a single float division. > - Memory Intensive: To represent 1/3 to infinite accuracy requires two- > integer-space (theoretically, 2 bytes). There are some numbers that > are hard to represent in fractions, yes, but in general those numbers > could be represented using two-long-space (variable-width longs). And > whenever accuracy isn't that important, it could be possible to create > a method that would lossily approximate the current fraction to an > acceptable length. Anyway, most computers nowadays is packed with > gigantic memory, why bother with such a small issue. > - Rationals must present themselves as decimal floats or it'll be > confusing: There will be no confusion in a good written code. > Progammers that writes good code would always use the 'behind-the- > scene' number, they wouldn't convert a previously 'string'ed number > back into calculation. And a convention can be created to represent a > fraction in a single line output (like * for multiplication, / for > division, they don't exist in paper maths) that would completely > eliminate any confusion of the user (well informed about the > convention, most people that never used computer before often tried to > use x and : to represent mult and div), even when the fractional > number is outputted to the foreground UI. -- http://mail.python.org/mailman/listinfo/python-list
