Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

  > For the first set, I meant to write:
  > [Prepend each string with infinite zeroes]
  > ...000
  > ...001
  > ...010
...

If there are infinitely many zeros on the front, you can't actually append anything. That doesn't end up being well-defined.

(Well, actually, there are transfinite ordinals, but that would confuse the issue. It's not what you mean, and it doesn't help)

  > Now all bit strings here have infinite length.
If you want to talk about an infinite "decimal" string, you need to talk about the things that come after the decimal point, in order. As such, they come in order, and you can't have infinitely many zeros and then a finite string on the end.

  > The string is still enumerable since this is just binary
  > encoding mapping to the set {0, 1, 2, 3, ...}
You need to be more careful about how you actually define the strings. Strings have a start, then they go on one place by one place.

  > The question still is if it covers all possible bit strings of
  > infinite length.
Well, you haven't actually properly defined strings, but even so, no. Everything you have starts with a zero.

  > For units place, we covered both zero and one.
No, you don't seem to have.

  > For (n+1)th place, we cover both zero and one
  > together with all combinations for the first (n) bits.
  > As n -> infinite, all possibilities get covered.
No, because as soon as you have a one in your expansion the string is finite, so not all possibilities are covered.

  > The question is if 111111111... is also there in this set.
  > But isn't it there too?
You defined the set - tell me where it is. Even leaving alone the fact that these aren't proper strings, it doesn't appear to be there.


>>> [Prepend each string with infinite zeroes] > ...000 > ...001 > ...010 >> If there are infinitely many zeros on the front, you can't actually append anything.

I am lost. In this first set, I do not have a decimal point anywhere. Why cannot I have an infinitely many zeros to the left of 1. It will still be just one when looked at as a number.

>> Strings have a start, then they go on one place by one place

As far as representing it as a string, I may still start from the right and work towards the left.

I understand your point for the decimal case, infinitely many zeroes on the right of decimal cannot be followed a finite string. My argument does not require this however. (I change ...00000011010 from the first set to .0101100000000... in the second set.)

>> > For units place, we covered both zero and one. >> No, you don't seem to have.

The units place is the rightmost below. Both zero and one are covered.

...000 ...001

Stating the above for the decimal case, let n=1 be the place right after the decimal, n=2 to the right of it, and so on. Now for place n=1, the both zero and one are covered (first two cases below). For n=2 place, again both zero and one are covered for all possible combinations above for n=1 place (first four cases below).

0.000000000000... 0.100000000000... 0.010000000000... 0.110000000000... 0.001000000000... 0.101000000000...

Using the mathematical induction argument, all combinations are covered. This must include 0.1111111111... It sits exactly where (simple) infinity sits in the enumerable set {0, 1, 2, 3, ... }


OK, so you're not talking about the usual diagonalisation. I'll try to follow what you've said and respond as I go.

  > In this first set, I do not have a decimal point anywhere.
OK, fine. But then you talked about flipping them around to come after the decimal point. When you do that you have only those strings that only have a finite number of 1s in them.

  > As far as representing it as a string, I may still start
  > from the right and work towards the left.
Yes you can, but that's not what people do when talking about Cantor and diagonalisation, so it's now completely unclear what you're talking about.

However, you start with finite strings of 0s and 1s, basically the non-negative whole numbers, represented as binary strings. Note that these are all finite, and the non-zero parts are still finite, even if you prepend an infinite number of 0s.

  > Stating the above for the decimal case, let n=1 be the
  > place right after the decimal, n=2 to the right of it, and
  > so on.
See, now you're talking about stuff after the decimal point. I'll continue ...

  > Now for place n=1, the both zero and one are covered
  > (first two cases below).
But for diagonalisation that's irrelevant. We only ask what is the first digit of the first number.

  > For n=2 place, again both zero and one are covered for
  > all possible combinations above for n=1 place
Again, irrelevant. We only ask what is the 2nd digit of the 2nd number.

  > 0.000000000000...
  > 0.100000000000...
  > 0.010000000000...
  > 0.110000000000...
  > 0.001000000000...
  > 0.101000000000...
So here if we construct the diagonal of this sequence as you've listed it we have 0.00000... Let me highlight the diagonal for you from this quoted section:

  > 0.0xxxxxxxxxxx...
  > 0.x0xxxxxxxxxx...
  > 0.xx0xxxxxxxxx...
  > 0.xxx0xxxxxxxx...
  > 0.xxxx0xxxxxxx...
  > 0.xxxxx0xxxxxx...
If we now flip this we get 0.11111....

Now observe that all of the strings you have contain only a finite number of 1s. That means that 0.11111... is not in your sequence.

  > Using the mathematical induction argument,
You haven't made an induction argument.

  > ... all combinations are covered.
For each place, both possibilities are eventually covered. but for each sequence that you give, it is eventually all zeros.

  > This must include 0.1111111111... 
No, it doesn't.

  > It sits exactly where (simple) infinity sits in
  > the enumerable set {0, 1, 2, 3, ... }
Infinity does not fit in that set, and 0.1111... is not in your defined set of numbers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: