Working with the set of real numbers (was: Finding size of Variable)

[Albert van der Horst]

In article <mailman.6735.1392194885.18130.python-list at python.org>,
Chris Angelico  <rosuav at gmail.com> wrote:
>On Wed, Feb 12, 2014 at 7:17 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>> Chris Angelico <rosuav at 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 at spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst