On 12 Jun., 04:54, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote: > In article <bfcd6301-e7f0-4ced-906d-c111d3784...@j32g2000yqh.googlegroups.com> WM <mueck...@rz.fh-augsburg.de> writes: > > On 11 Jun., 15:46, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote: > > > In article <8d9c63c5-b605-4a98-81f2-815875aae...@21g2000vbk.googlegroups.= > > com> WM <mueck...@rz.fh-augsburg.de> writes: > ... > > > > > Because you do not check the lines in order. It is always your > > > > > basic assumption that you first check the first line and after > > > > > that the next line. That is wrong. > > > > > > > > That is necessary because you cannot find the n-th line unless you > > > > know the line number n - 1 or some equivalent mark. > > But why is getting the number n in any way related to the checking of the > previous lines?
Because by blind choice you cannot be sure to hit what you want. > > > > You are wrong. A list is a mapping from N to the elements of the list. > > > Through that list, given a number n, you find the n-th element of the list > > > without referring to any previous elements of the list. > > > > But you cannot find number n without referring to the numbers less > > than n. > > That does not mean that you check the line with number n. So you assertion > that you need to check all lines in order is false.
In unary or in von Neumann's representation there is the whole counting process incorporated in each number. In decimal, you need only count the powers of 10. Anyhow addressing a number means counting. > > > > To give an example, > > > let's have a list of positive rational numbers through the mapping given > > > a lnong time ago by David Tribble. To get the 51st element of the list, > > > we calculate the mapping: write 51 in binary, create from it a continued > > > fraction as described on > > > <http://homepages.cwi.nl/~dik/english/mathematics/mueck/mapping.html> > > > which is [0, 1, 2, 3], calculate it and we find 7/9. So we know the > > > 51st element without knowing the 50th element. Where did I come at the > > > 47th rational in that list (which is 7/11)? > > > > How can you write 51 without knowing what it is? Of course you must > > count. In unary this is more difficult than in decimal or binary, but > > the principle is the same. How do you obtain this number > > 1111111111111111111111111111111111111 > > unless you count the digits? > > So you agree now that you can check the n-th element of the list before > checking any previous elements of the list? (How you get at n is irrelevant > here, because getting at n does not involve checking lines preceding the > n-th line.)
Of course you can check the n-th element before checking any other. But in order to find the n-th element, you have to count from 1 to n, either in unary or at least in the powers of 10. Therefore it is not correct to talk about simultaneity. > > Pray use tail in the future rather than end, to avoid confusion.
So Ido. > > > > > Every end of a path contains aleph_0 nodes. > > > > These nodes can be mapped on that path. Every node will eventually be > > > > mapped on one path. Therefore all nodes are used up for constructing > > > > a countable set of paths. > > > > > > Perhaps right, depends on how you actually do define things. But are > > > there nodes mapped to all paths? That is what you assert. > > > > Unless there is at least one node occupied by the path p_n that is not > > occupied by the paths p_0 to p_n-1, p_n is not a new path. > > Assuming countability again.
Countability of nodes only. I am only interested to cover every node, i.e., to exhaust the tree. I am a follower of Eudoxos.
> Suppose we have the set of paths where each > path goes to the right after some specific (for that path) node.
That would imply all paths with tails 111... No problem.
> Is there > a node in your tree that is not occupied by any of the paths in that set?
No, it isn't. Every path node is occupied by at least the head of a path.
> Are there possible other paths that are *not* in that set of paths (like > a path that alternates going left and right)?
It is said so. But there is no possibility, after having completed the construction, to introduce such a path. They have sneaked in. > > > > Not in this case bacause you apply the words to different things. > > > *Unless* you assume that what is valid in finite cases also is valid > > > in infinite cases. But let's see: > > > sum{i = 0 .. n} 1/(i!) > > > is a rational number. So according to your logic: > > > e = sum{i = 0 .. n} 1/(i!) > > > is also a rational number. > > > > I don't see a difference. But I can assuer you, there is no decimal > > expansion for irrational numbers. > > Where am I talking about decimal expansions? According to you the > in finite sum above (which equals e by definition) is rational. Is that > true?
True is: There are only rational sums of decimal or binary expansions. > > > > > > Ok. The logic of finite complete sums of rational elements gives > > > > > that the sum is rational. Using your logic we get that the complete > > > > > (i.e. in the limit) sum of rational elements is also rational. And > > > > > so by that logic, e, pi and whatever are rational, and all numbers > > > > > we do use are rational. > > > > > > > > In fact there are no binary expansions of irrational numbers. > > > > > > What is the relevance? Where am I talking about binary expansions? > > > > Binary, decimal, whatever. It does not exist. > > I am not talking about whatever expansion. Pray keep to the question. > According to your logic the complete (i.e. in the limit) sum of rational > elements is also rational. And so by that logic, e, pi and whatever are > rational and all numbers we do use are rational.
No. The limit is not rational. But the limit cannot be represented by a sequence. Therefore the limit is not in any Cantor-list. That is the big error of set theory: to believe that irrational numbers have rational representations. Every binary or decimal sequence is a rational representation.
I skip the rest because the main point now has become fairly clear: The paths in the binary tree. We should concentrate on that problem.
