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

I'll try to give some short pointers.

1. Matrices represent linear functions between finite-dimensional vector spaces. That is, if you have a function f from V to W that satisfies f(ax + by) = af(x) + bf(y), then there is a matrix A such that f(x) = Ax, and vice versa.

Once you understand that, try to figure out what happens to those matrices when you compose functions. In other words, when you define h(x) = g(f(x)) (assuming that f and g are linear maps that can be composed in this way), then given the matrices for g and f, what will the matrix for h look like? You will end up with exactly the rules for matrix multiplication.

The reason that you call this result "multiplication" is simply that it behaves very much like the multiplication that you are used to from the reals. In particular, you get a ring on square matrices, with (matrix) addition and multiplication that satisfy a distributive law.

2. I personally think that those angles are a bit of a red herring. In particular, the cross product generalizes in a somewhat more complicated way to higher dimensions, and then you have to talk about determinants instead of angles. That would take too much time and space to explain properly here.

3. Set and the "element-of" relation are not defined in the usual sense. They are indeed simply assumed, and you just postulate the properties that they need to satisfy, a.k.a. the axioms of set theory. It's a way of thinking that takes some getting used to, but as an analogy, try to work through Euclid. He doesn't define points or lines, either, but only postulates properties that they need to satisfy.

4. Because 0.9999... is usually interpreted as a real number, and not as an infinite sequence of characters. As a real number, 0.9999... has no meaning except as a limit, and hence they must be equal. As infinite sequences of characters, 0.9999... and 1 are of course different, but that's not how we usually interpret them.

If you think that this is in your way when understanding Cantor's infinities, perhaps you should try to use the diagonalisation argument on infinite bit strings instead of on real numbers. That way, those kinds of subtleties simply do not arise.



Here is what I am confused about with regards to diagonalisation:

Start with binary non-negative integers: 000 001 010 011 100 101 ... (goes to infinity)

This set now includes all possible bit strings of infinite length since the way these are iteratively generated includes all possibilities.

This is also an enumerable set by definition.

Let's now reverse the bits and put them after a decimal. These are just real numbers now going from zero to one. (This step is actually unnecessary I think.) .000 .100 .010 .110 .001 .101 .011 ...

This must be enumerable set too.

Using diagonalisation argument, .111111 is never to be found in this set. This is exactly where I am stuck. This number comes into the set from flipping of infinity in the original set, which includes all possible stings of infinite length.

I immediately read into your message on treating these as bit strings instead of real numbers. I still am stuck though. (Do you also see a connection to 0.99999... by the way?)


  > Start with binary non-negative integers:
  > 000 001 010 011 100 101 ... (goes to infinity)

  > This set now includes all possible bit strings of
  > infinite length
No, it only contains the strings of finite length. There are infinitely many of them, but each one stops after a while. In particular, then n^th one only has log2(n) places before it then becomes all 0s.

  > This is also an enumerable set by definition.
Yes.

  > Let's now reverse the bits and put them after a decimal.
  > These are just real numbers now going from zero to one.
  > ... .000 .100 .010 .110 .001 .101 .011 ...
But not all of them, since these are only those numbers that have a finite number of 1's in them.

  > This must be enumerable set too.
Yes it is.

  > Using diagonalisation argument, .111111 is never to be
  > found in this set.
Irrelevant.

  > This is exactly where I am stuck. This number comes
  > into the set from flipping of infinity in the original set,
"Infinity" was never in your original set. And if it was, it wouldn't be produced by the diagonalisation argument.

  > which includes all possible strings of infinite length.
No it doesn't.


For the first set, I meant to write:

[Prepend each string with infinite zeroes]

...000

...001

...010

...011

...100

...101

...000

Now all bit strings here have infinite length.

The set is still enumerable since this is just binary encoding mapping to the set {0, 1, 2, 3, ...}

The question still is if it covers all possible bit strings of infinite length.

For units place, we covered both zero and one. 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.

The question is if 111111111... is also there in this set. But isn't it there too?


  > 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.


Edit: This comment should be read after my comment below this. It shows up first on HN.

If infinity was in the original set, what would diagonalisation produce? [Genuinely asking, I am unclear on this.] I am flipping all the bits along a diagonal and they are all zeros before flipping.

If 0.99999... = 1, then using my argument of flipping the bits around the decimal, wouldn't infinity be in the set?


  > If infinity was in the original set,
What does this mean? Your complete imprecision is making it impossible to answer the questions, despite wanting to help, because they don't make sense.

What set? Define it clearly. Don't talk about infinite strings of zeros followed by stuff, because in the context of decimal or binary expansions that doesn't make sense. Strings have a start, then they go on one place at a time.,

  > I am flipping all the bits along a diagonal and they
  > are all zeros before flipping.
If they are all zero before flipping then 0.11111... isn't there. You've stated that the n^th number has 0 in the n^th place. That means 0.11111... is not the n^th number for any n.

If 0.99999... = 1, then using my argument of flipping the bits around the decimal, wouldn't infinity be in the set?


>> If they are all zero before flipping then 0.11111... isn't there.

This helps. Since the first set has infinitely many zeros on the left, flipping around the decimal means there would have to be infinitely many zeros somewhere on the right. 0.1111.... however has infinitely many ones before these supposed infinitely many zeroes, which cannot be for the same reason that a finite string with one cannot be after infinitely many zeroes at the right of a decimal.

This means that the first set does not have 111111...

So if I keep incrementing binary numbers, I'll never reach 11111... within the limits of enumerability.

I need to think and read more. The above seems to imply that the simple infinity is not in the enumerable set. But I may be confused again.

>> You've stated that the n^th number has 0 in the n^th place. That means 0.11111... is not the n^th number for any n.

I have been confused about this. Somehow 0.11111... is not in the set, in spite of the mathematical induction proof I supply. I need to think more. The proof must be incomplete (or imprecise as you say).


> This set now includes all possible bit strings of infinite length since the way these are iteratively generated includes all possibilities.

That's not correct -- in fact, it contains no infinite bit strings at all (to prove this to yourself, ask at what position the first infinite string appears).


Please see my response to Colin. Sorry for me not having this stated right the first time.


Thanks!!

>> then you have to talk about determinants instead of angles

I certainly never heard this before. (I know how to calculate determinants, but never quite developed intuition around them.) Can you please say some more on this? :-)


Take a matrix M. This is a linear transformation. Look at what happens to the unit cube, and ask what volume the result has?

The answer is the determinant of the matrix.


Ah, what the heck. Here's how I think about this, which is heavily influenced by working on some problems related to lattices (from the geometry of numbers).

How could you generalize the cross product to higher dimension? What the cross product does is that it takes two linearly independent 3-dim vectors and gives you some kind of canonical vector orthogonal to both of them.

Can you find a reasonably canonical operation that, given two linearly independent d-dim vectors gives you some kind of canonical vector orthogonal to both of them? The answer is basically no.

However, you can find a reasonable operation that, given d-1 linearly independent d-dim vectors a(1) ... a(d-1), gives you a canonical vector v orthogonal to all of them. This vector should be the unique solution of a system of linear equations aj * v = 0, z * v = 1.

One way to resolve such a system is using Cramer's rule: each coordinate of v is a determinant of the matrix A of the system with one column replaced by the right-hand side, divided by the determinant of A. There are a number of reasons for not liking this division: (1) it is impractical if you prefer to work with coefficient in a ring (such as the integers) instead of a field; (2) the cross product is defined without any divisions; (3) the determinant of A depends on your choice of z, but the determinants in the numerators do not depend on the choice of z. So we just forget about the division, which is the same as choosing z such that det(A) = 1.

That gives you a higher-dimensional generalization of the cross product. Okay, so now how long is v going to be?

Well, for that you have to understand that the volume of the parallelepiped (skewed box) spanned by linearly independent vectors is equal to the determinant of the matrix that contains those vectors as rows or columns (or the square-root of the matrix multiplied with its transpose if you don't have a full-dimensional set). There are a number of ways to see this; one of them is that the parallelepiped is obtained via a linear transformation of the unit cube by that matrix, and linear transformations scale volume by the (absolute value of) the determinant.

So the determinant of A is the height of z over the hyperplane spanned by a(1) ... a(d-1) times the (d-1)-dimensional volume of the parallelepiped spanned by them. This means that the height of z is the inverse of that volume (becaues we chose z so that det(A) = 1). But then since z * v = 1, the length of v must be equal to that volume, so that the volume and its inverse cancel.

Now go back to the case d=3 and compute the size of the parallelepiped (aka parallelogram) spanned by your two starting vectors. Voila, you get exactly the formula for the length of the cross product. Compute the square-root of the determinant that you get when you multiple the matrix containing the two vectors as rows with its transpose. Voila, you get exactly the same formula again :)

(In fact, if you look at how the components of the cross product in d=3 are computed, you'll find the 2x2 subdeterminants of that 2x3 matrix - and that fits perfectly with what I wrote above about using Cramer's rule.)




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

Search: