On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevide...@gmail.com> wrote: > I think you misunderstood what I was saying. > > It's not *possible* to represent a real number abstractly in any digital > computer. Python couldn't have an "abstract real number" type even it wanted > to.
True, but why should the "non-integer number" type be floating point rather than (say) rational? Actually, IEEE floating point could mostly be implemented in a two-int rationals system (where the 'int' is arbitrary precision, so it'd be Python 2's 'long' rather than its 'int'); in a sense, the mantissa is the numerator, and the scale defines the denominator (which will always be a power of 2). Yes, there are very good reasons for going with the current system. But are those reasons part of the details of implementation, or are they part of the definition of the data type? > (Math aside: Real numbers are not countable, meaning they cannot be put into > one-to-one correspondence with integers. A digital computer can only > represent countable things exactly, for obvious reasons; therefore, to model > non-countable things like real numbers, one must use a countable > approximation like floating-point.) Right. Obviously a true 'real number' representation can't be done. But there are multiple plausible approximations thereof (the best being rationals). Not asking for Python to be changed, just wondering why it's defined by what looks like an implementation detail. It's like defining that a 'character' is an 8-bit number using the ASCII system, which then becomes problematic with Unicode. (Ohai, C, didn't notice you standing there.) Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
