Finding size of Variable

C

Chris Angelico

Well, if your idealized, infinite, digital computer had ℵ₠bytes of RAM
and ran at ℵ₠hertz and Python supported transfinite iteration, you
could easily do reals:

def real_sqrt(y):
for x in continuum(0, max(1, y)):
# Note: x is not traversed in the < order but some other
# well-ordering, which has been proved to exist.
if x * x == y:
return x
assert False

How exactly do you iterate over a continuum, with a digital computer?
Even adding to your requirements that it have an ℵ₠Hz bus (which, by
the way, I *totally* want - the uses are endless), it would take a
finite amount of time to assign to x the "next number", ergo your
algorithm can't guarantee to finish in finite time.

ChrisA
 
M

Marko Rauhamaa

Chris Angelico said:
How exactly do you iterate over a continuum, with a digital computer?

How "digital" our idealized computers are is a matter for a debate.
However, iterating over the continuum is provably "possible:"

http://en.wikipedia.org/wiki/Transfinite_induction
it would take a finite amount of time to assign to x the "next
number", ergo your algorithm can't guarantee to finish in finite time.

My assumption was you could execute ℵ₠statements per second. That
doesn't guarantee a finite finish time but would make it possible. That
is because

ℵ₠* ℵ₠= ℵ₠= ℵ₠* 1

This computer is definitely more powerful than a Turing machine, which
only has ℵ₀ bytes of RAM and thus can't even store an arbitrary real
value in memory.


Marko
 
C

Chris Angelico

My assumption was you could execute ℵ₠statements per second. That
doesn't guarantee a finite finish time but would make it possible. That
is because

ℵ₠* ℵ₠= ℵ₠= ℵ₠* 1

Hmm. I never actually covered this stuff in grade school - the
construction of infinite computing power didn't exactly come up. But
as I understand it, just calculating the "next number" requires ℵ₠RAM
operations, and you have to do that ℵ₠times per second. Sowhat
you're saying is that it's possible to do that? You can execute ℵâ‚
operations where each operation has to wait for ℵ₠bus actions before
continuing?

This would do my head in if I hadn't already thoroughly broken my
brain on other insanities.

ChrisA
 
R

Rotwang

What's this? A discussion about angels dancing on a the head of a pin?
Great, I'm in.

Well, if your idealized, infinite, digital computer had ℵ₠bytes of RAM
and ran at ℵ₠hertz and Python supported transfinite iteration, you
could easily do reals:

def real_sqrt(y):
for x in continuum(0, max(1, y)):
# Note: x is not traversed in the < order but some other
# well-ordering, which has been proved to exist.
if x * x == y:
return x
assert False

The function could well return in finite time with a precise result for
any given nonnegative real argument.


Minor point: ℵ₠does not mean the cardinality c of the continuum, it
means the smallest cardinal larger than ℵ₀. It has been proved that the
question of whether ℵ₠== c is independent of ZFC, so it is in a sense
unanswerable.

More importantly, though, such a computer could not complete the above
iteration in finite time unless time itself is not real-valued. That's
because if k is an uncountable ordinal then there is no strictly
order-preserving function from k to the unit interval [0, 1]. For
suppose otherwise, and let f be such a function. Let S denote the set of
successor ordinals in k, and let L denote the set of limit ordinals in
k. Then lambda x: x + 1 is an injective function from L (or L with a
single point removed if k is the successor of a limit ordinal) to S, so
that S is at least as large as L and since k == S | L it follows that S
is uncountable.

For each x + 1 in S, let g(x + 1) = f(x + 1) - f(x) > 0. Let F be any
finite subset of S and let y = max(F). It is clear that f(y) >= sum(g(x)
for x in F). Since also f(y) <= 1, we have sum(g(x) for x in F) if <= 1
for all finite F. In particular, for any integer n > 0, the set S_n = {x
for x in S if g(x) > 1/n} has len(S_n) < n. But then S is the union of
the countable collection {S_n for n in N} of finite sets, so is
countable; a contradiction.


My assumption was you could execute ℵ₠statements per second. That
doesn't guarantee a finite finish time but would make it possible. That
is because

ℵ₠* ℵ₠= ℵ₠= ℵ₠* 1

I don't think that's enough - assuming the operations of your processor
during a second can be indexed by some ordinal k with len(k) == c, if
each of the c operations per iteration must be complete before the next
step of the for loop is complete then you need an injective function
from c * c to k that preserves the lexicographic ordering. I don't know
whether such a function exists for arbitrary such k, but k can be chosen
in advance so that it does.
 
M

Marko Rauhamaa

Rotwang said:
for x in continuum(0, max(1, y)):
# Note: x is not traversed in the < order but some other
# well-ordering, which has been proved to exist.
if x * x == y:
return x

[...]

More importantly, though, such a computer could not complete the above
iteration in finite time unless time itself is not real-valued. That's
because if k is an uncountable ordinal then there is no strictly
order-preserving function from k to the unit interval [0, 1].

If you read the code comment above, the transfinite iterator yields the
whole continuum, not in the < order (which is impossible), but in some
other well-ordering (which is known to exist). Thus, we can exhaust the
continuum in ℵ₠discrete steps.

(Yes, the continuum hypothesis was used to make the notation easier to
read.)


Marko
 
R

Rotwang

Rotwang said:
for x in continuum(0, max(1, y)):
# Note: x is not traversed in the < order but some other
# well-ordering, which has been proved to exist.
if x * x == y:
return x

[...]

Restoring for context:
More importantly, though, such a computer could not complete the above
iteration in finite time unless time itself is not real-valued. That's
because if k is an uncountable ordinal then there is no strictly
order-preserving function from k to the unit interval [0, 1].

If you read the code comment above, the transfinite iterator yields the
whole continuum, not in the < order (which is impossible), but in some
other well-ordering (which is known to exist). Thus, we can exhaust the
continuum in ℵ₠discrete steps.

Yes, I understood that. But my point was that it can't carry out those
ℵ₠discrete steps in finite time (assuming that time is real-valued),
because there's no way to embed them in any time interval without
changing their order. Note that this is different to the case of
iterating over a countable set, since the unit interval does have
countable well-ordered subsets.
 
M

Marko Rauhamaa

Rotwang said:
But my point was that it can't carry out those ℵ₠discrete steps in
finite time (assuming that time is real-valued), because there's no
way to embed them in any time interval without changing their order.

I'd have to think so I take your word for it.


Marko
 
G

Gregory Ewing

Dave said:
Actually, the particular example you use can be done. When
printing the infinite sum of two infinite decimal streams, you
can simply hold back whenever you get one or more nines.

But you only have a finite amount of space for keeping
track of how many nines you've seen, so there will be
some inputs with more nines than you can handle.
(Infinitely many such inputs, in fact!)
 
D

Devin Jeanpierre

How "digital" our idealized computers are is a matter for a debate.
However, iterating over the continuum is provably "possible:"

http://en.wikipedia.org/wiki/Transfinite_induction

You missed the most important point on that page, which is the "limit case"..

There is no way to iterate over all the reals one at a time, no matter
how fast you execute instructions. If you could, it would be trivial
to show that the reals have the same cardinality as the positive
integers: correspond n with the whatever is returned by the nth call
to it.next.

It doesn't matter if you call your magical iterator "transfinite",
that doesn't make it so.

-- Devin
 
G

Gregory Ewing

Chris said:
Even adding to your requirements that it have an ℵ₠Hz bus (which, by
the way, I *totally* want - the uses are endless), it would take a
finite amount of time to assign to x the "next number", ergo your
algorithm can't guarantee to finish in finite time.

If it's a quantum computer, it may be able to execute
all branches of the iteration in parallel. But it
would only have a probability of returning the right
answer (in other cases it would kill your cat).
 
G

Gregory Ewing

Devin said:
There is no way to iterate over all the reals one at a time, no matter
how fast you execute instructions. If you could, it would be trivial
to show that the reals have the same cardinality as the positive
integers: correspond n with the whatever is returned by the nth call
to it.next.

You're assuming that the calls to it.next are discrete
events separated by some nonzero time interval.

A decent transfinite processor would make a continuum
of calls, and execute uncountably many of them in any
finite period of time.
 
G

Grant Edwards

If it's a quantum computer, it may be able to execute
all branches of the iteration in parallel. But it
would only have a probability of returning the right
answer (in other cases it would kill your cat).

I know somebody who would claim that _is_ the right answer.
 
A

Albert van der Horst

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.
Traceback (most recent call last):
File "<pyshell#1>", line 1, in <module>
float("pi")
ValueError: could not convert string to float: 'pi'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.)

Groetjes Albert
 
C

Chris Angelico

To be more precise: a subset of the rational numbers, those with a denominator
that is a power of two.

And no more than N bits (53 in a 64-bit float) in the numerator, and
the denominator between the limits of the exponent. (Unless it's
subnormal. That adds another set of small numbers.) It's a pretty
tight set of restrictions, and yet good enough for so many purposes.

But it's a far cry from "all real numbers". Even allowing for
continued fractions adds only some more; I don't think you can
represent surds that way.

ChrisA
 
R

Rustom Mody

And no more than N bits (53 in a 64-bit float) in the numerator, and
the denominator between the limits of the exponent. (Unless it's
subnormal. That adds another set of small numbers.) It's a pretty
tight set of restrictions, and yet good enough for so many purposes.
But it's a far cry from "all real numbers". Even allowing for
continued fractions adds only some more; I don't think you can
represent surds that way.

See

http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html#sqrts
 
R

Rustom Mody

That's neat, didn't know that. Is there an efficient way to figure
out, for any integer N, what its sqrt's CF sequence is? And what about
the square roots of non-integers - can you represent √π thatway? I
suspect, though I can't prove, that there will be numbers that can't
be represented even with an infinite series - or at least numbers
whose series can't be easily calculated.

You are now asking questions that are really (real-ly?) outside my capacities.

What I know (which may be quite off the mark :) )

Just as all real numbers almost by definition have a decimal form (may
be infinite eg 1/3 becomes 0.33333...) all real numbers likewise have a CF form

For some mathematical (aka arcane) reasons the CF form is actually better.

Furthermore:

1. Transcendental numbers like e and pi have non-repeating infinite CF forms
2. Algebraic numbers (aka surds) have repeating maybe finite(?) forms
3. For some numbers its not known whether they are transcendental or not
(vague recollection pi^sqrt(pi) is one such)
4 Since e^ipi is very much an integer, above question is surprisingly non-trivial
 
S

Steven D'Aprano

That's neat, didn't know that. Is there an efficient way to figure out,
for any integer N, what its sqrt's CF sequence is? And what about the
square roots of non-integers - can you represent √π that way? I suspect,
though I can't prove, that there will be numbers that can't be
represented even with an infinite series - or at least numbers whose
series can't be easily calculated.

Every rational number can be written as a continued fraction with a
finite number of terms[1]. Every irrational number can be written as a
continued fraction with an infinite number of terms, just as every
irrational number can be written as a decimal number with an infinite
number of digits. Most of them (to be precise: an uncountably infinite
number of them) will have no simple or obvious pattern.


[1] To be pedantic, written as *two* continued fractions, one ending with
the term 1, and one with one less term which isn't 1. That is:

[a; b, c, d, ..., z, 1] == [a; b, c, d, ..., z+1]


Any *finite* CF ending with one can be simplified to use one fewer term.
Infinite CFs of course don't have a last term.
 
C

Chris Angelico

Every irrational number can be written as a
continued fraction with an infinite number of terms, just as every
irrational number can be written as a decimal number with an infinite
number of digits.

It's easy enough to have that kind of expansion, I'm wondering if it's
possible to identify it directly. To render the decimal expansion of a
square root by the cut-and-try method, you effectively keep dividing
until you find that you're "close enough"; that means you (a) have to
keep the entire number around for each step, and (b) need to do a few
steps to find that the digits aren't changing. But if you can take a
CF (finite or infinite) and do an O(n) transformation on it to produce
that number's square root, then you have an effective means of
representing square roots. Suppose I make a generator function that
represents a fraction:

def one_third():
while True:
yield 3

def one_seventh():
while True:
yield 1; yield 4; yield 2; yield 8; yield 5; yield 7

I could then make a generator that returns the sum of those two:

def add_without_carry(x, y):
whiile True:
yield next(x)+next(y)

Okay, that's broken for nearly any case, but with a bit more sophistication:

def add(x, y):
prev=None
nines=0
while True:
xx,yy=next(x),next(y)
tot=xx+yy
if tot==9:
nines+=1
continue
if tot>9:
if prev is None: raise OverflowError("exceeds 1.0")
yield prev+1
tot-=10
for _ in range(nines): yield 0
nines=0
else:
if prev is not None: yield prev
prev=tot

def show(n):
return ''.join(str(_) for _ in itertools.islice(n,20))
'85714285714285714285'

In constant space, that will produce the sum of two infinite sequences
of digits. (And it's constant time, too, except when it gets a stream
of nines. Adding three thirds together will produce an infinite loop
as it waits to see if there'll be anything that triggers an infinite
cascade of carries.) Now, if there's a way to do that for square
rooting a number, then the CF notation has a distinct benefit over the
decimal expansion used here. As far as I know, there's no simple way,
in constant space and/or time, to progressively yield more digits of a
number's square root, working in decimal.

ChrisA
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top