In article <mailman.6735.1392194885.18130.python-l...@python.org>, Chris Angelico <ros...@gmail.com> wrote: >On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: >> Chris Angelico <ros...@gmail.com> writes: >> >>> I have yet to find any computer that works with the set of real >>> numbers in any way. Never mind optimization, they simply cannot work >>> with real numbers. >> >> Not *any* computer? Not in *any* way? The Python built-in âfloatâ type >> âworks with the set of real numbersâ, in a way. > >No, the Python built-in float type works with a subset of real numbers:
To be more precise: a subset of the rational numbers, those with a denominator that is a power of two. > >>>> float("pi") >Traceback (most recent call last): > File "<pyshell#1>", line 1, in <module> > float("pi") >ValueError: could not convert string to float: 'pi' >>>> float("Ï") >Traceback (most recent call last): > File "<pyshell#2>", line 1, in <module> > float("Ï") >ValueError: could not convert string to float: 'Ï' > >Same goes for fractions.Fraction and [c]decimal.Decimal. All of them >are restricted to some subset of rational numbers, not all reals. > >> The <URL:http://docs.python.org/2/library/numbers.html#numbers.Real> ABC >> defines behaviours for types implementing the set of real numbers. >> >> What specific behaviour would, for you, qualify as âworks with the set >> of real numbers in any wayâ? > >Being able to represent surds, pi, e, etc, for a start. It'd >theoretically be possible with an algebraic notation (eg by carrying >through some representation like "2*pi" rather than 6.28....), but >otherwise, irrationals can't be represented with finite storage and a >digit-based system. An interesting possibility is working with rules that generate the continued fraction sequence of a real number. Say yield() gives the next coefficient (or the next hex digit). It was generally believed that summing two numbers in their cf representation was totally impractical because it required conversion to a rational number. OTOH if we consider a cf as an ongoing progress, the situation is much better. Summing would be a process that yields coefficients of the sum, and you could just stop when you've enough precision. Fascinating stuff. It is described in a self contained, type writer style document gosper.txt that is found on the web in several places e.g. http://home.strw.leidenuniv.nl/~gurkan/gosper.pdf I have a gosper.txt, don't know from where. It really is a cookbook, one could built a python implementation from there, without being overly math savvy. I'd love to hear if some one does it. ( in principle a coefficient of a cf can overflow machine precision, that has never been observed in the wild. A considerable percentage of the coefficients for a random number are ones or otherwise small. The golden ratio has all ones.) > >ChrisA Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
-- https://mail.python.org/mailman/listinfo/python-list