Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #6784
| References | <mailman.2351.1306897552.9059.python-list@python.org> <b7b526f5-c839-4b3e-8e00-eee8a19078ce@glegroupsg2000goo.googlegroups.com> |
|---|---|
| Date | 2011-06-01 13:57 +1000 |
| Subject | Re: float("nan") in set or as key |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.2354.1306900680.9059.python-list@python.org> (permalink) |
On Wed, Jun 1, 2011 at 1:30 PM, Carl Banks <pavlovevidence@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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: float("nan") in set or as key Carl Banks <pavlovevidence@gmail.com> - 2011-05-31 20:30 -0700
Re: float("nan") in set or as key Roy Smith <roy@panix.com> - 2011-05-31 23:43 -0400
Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-06-01 14:04 +0000
Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-01 13:57 +1000
Re: float("nan") in set or as key Ben Finney <ben+python@benfinney.id.au> - 2011-06-01 15:18 +1000
Re: float("nan") in set or as key Jerry Hill <malaclypse2@gmail.com> - 2011-06-01 09:44 -0400
Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-06-02 02:12 +1000
csiph-web