Talk:Geometric algebra: Difference between revisions
→This task is a mess
| (16 intermediate revisions by 2 users not shown) | |||
Line 105:
::::::::::::::After thinking about this, I am going to ask you to change your "It is known" statements in the task description. You need to spell these out in more detail. You cannot expect these details to be known by typical contributors to Rosettacode. You cannot even expect these details to be known by typical mathematicians. Only people who are well versed in the geometri/clifford algebra arcana should be expected to have apriori understanding of those details. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 03:31, 20 October 2015 (UTC)
:::::::::::::::The axioms define a so-called geometric product. The fact that this geometric product can be applied to a scalar and something else does not make it a scalar product. The expression ''scalar product'' in math means something specific. IIRC it's a symmetric, bilinear, positive-definite form. The multiplication of a scalar by a vector in a vector space for instance is never called scalar product, as this would be a very unfortunate naming collision. IIRC it's called extern scalar multiplication or something like that.
:::::::::::::::The proof that the geometric product defines a scalar product is not too hard. First you define the inner product of two vectors <math>\mathbf{a}\cdot\mathbf{b} = (\mathbf{a}
:::::::::::::::It's not very complicated a proof, but it's quite irrelevant to the task and putting it in the description would spam it imho. I won't add it unless other people complain.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 11:21, 20 October 2015 (UTC)
:::::::::::::::: The axioms themselves do not specify what kind of product they use - which means that the reader should be able to determine that. Of course, other statements will constrain this, but baring considerable familiarity with the topic, we are left with the sort of trial and error (or hypothesis and test) that leads to talk pages as large as this one. Put differently, a general problem with generality is that there's so many ways to do it, and so many of the underlying assumptions are just that: assumptions. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 11:47, 20 October 2015 (UTC)
::::::::::::::::: The axioms don't specify what kind of product they use because they ''define'' it. Any product that satisfy these axioms '''IS''' a geometric product. That's what axioms do.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 12:01, 20 October 2015 (UTC)
::::::::::::::::::One difficulty here is that the definition uses the term "dimension". And, while we might reasonably assume that we know what a "[[Dimension_(vector_space)|dimension]]" is, you have also declared that multivectors are not vectors. This means that we should not be using the definition of dimension which applies to vectors. I hope you can see the difficulty... --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 13:29, 20 October 2015 (UTC)
:::::::::::::::::::I've explained that already. Strictly speaking, multivectors are vectors, but the term ''vector'' is reserved to elements of <math>\mathcal{V}</math>. The task description also briefly mentions this.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 14:22, 20 October 2015 (UTC)
== "Orthonormal basis" ==
Line 153 ⟶ 156:
:::: The trick, here, seems to be that in this context we use multiple conflicting concepts of the term "dimension" and, for related terms such as "scalar" and "vector". A thorough exposition would detail each of these uses and show - ideally through concrete examples - how each of them is relevant to the implementation, as well as how each of these uses is different from the other uses of the same word, and perhaps the phrasing conventions we should be using to distinguish between these cases. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 17:55, 19 October 2015 (UTC)
A current problem with this task is that it only tests for symmetric results.
In other words, the javascript implementation would work even if the multiply routine were changed from
<lang javascript>...
for (var i in a) {
if (a[i]) {
for (var j in b) {
if (b[j]) {
...</lang>
to
<lang javascript>...
for (var i in a) {
if (a[i]) {
var j= i;
if (b[j]) {
...</lang>
Obviously, "quaternions" which result from this kind of implementation would not be real quaternions. But, this is an easy mistake to make. And, to underline this, one of the J implementations currently features this mistake. Fixing it is trivial, but not necessary as the task is currently written.
But also display of asymmetric results seems both ugly and difficult to interpret, so I'll just mention that this is how the task is currently written. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 10:11, 21 October 2015 (UTC)
:The only way I can understand what you've just wrote here is by assuming you have again confused the geometric product and the inner product.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 10:25, 21 October 2015 (UTC)
::Hmm... you are correct. Testing this, I see that the javascript implementation does indeed give different results with this change. But looking at that flawed J implementation, the deviation from the javascript implementation is real. To simulate it in the javascript implementation, you would need to consider the i and j values as members of a list and only combine values from a/b where the i list and the j list had the same index. Anyways,, I'll let you come up with a change to the task description to catch this issue - if it matters to you. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 12:43, 21 October 2015 (UTC)
== The J solution might be correct but too small ==
Line 191 ⟶ 220:
:Put differently: all of the implementations here which I have inspected use index 0 to represent the "scalar part" of the "multivector". However, the scalar part of the multivector is not orthogonal to the elements of the orthogonal basis. Specifically, in these implementations, e(0) here corresponds to index 1 of the multivector, e(1) corresponds to index 2 of the multivector, e(2) corresponds to index 4 of the multivector, e(3) corresponds to index 8 of the multivector and e(4) corresponds to index 16 of the multivector. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 17:14, 19 October 2015 (UTC)
== This task is a mess ==
I'm considering going back to verifying the axioms. I would add a verification that <math>\mathcal{V}</math> is of dimension at least 5, though. That should prevent implementations of trivial algebras and re-use of the quaternion.
In order to verify the contraction rule, I would require the test to be done on a large number of random vectors.
Possibly also displaying the multiplication table, as in the echolisp solution.
--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 14:54, 21 October 2015 (UTC)
I'm not sure what your issues are, but it seems to me that quaternions are an algebra containing a vector space \mathcal{V} and obeying these axioms:
:<math>\begin{array}{c}
(ab)c = a(bc)\\
a(b+c) = ab+ac\\
(a+b)c = ac+bc\\
\forall \mathbf{x}\in\mathcal{V},\,\mathbf{x}^2\in\R
\end{array}
</math>
You've added other constraints onto the task (such as the calculation that generates a 19, the orthonormal basis for \mathcal{V} and the requirement for two different embedded quaternion algebras), and I guess I can agree that that aspect is something of a mess. Mathematically speaking, I suppose that this hints at the need for further axioms... but computationally speaking, usually all we can ever provide is an implementation which approximates the math.
For example, no real computer implementation can satisfy the Peano postulates, so there will be cases where simple addition fails. And multiplication is even worse. Roughly half of the result domain for addition is typically missing, but for multiplication the size of the valid argument domain approximates the square root of the size of the result domain. So that sort of thing is going to be completely valid, mathematically...
Which I think has to do with why we get into concrete examples and/or concrete requirements - those might be "unnecessary" from a mathematical point of view, but they can be critically important from an implementation point of view. I think this also has something to do with why it's often a good idea to avoid an overly-general implementation...
So, anyways, from a mathematical purist point of view, I can't imagine many tasks can be anything but a "mess".
Though, I guess we could use Boolean addition and multiplication (greatest common divisor and least common multiple) or maybe modulo arithmetic - that would work around the overflow problems with regular addition and multiplication. This probably is not what you intend - might even violate the task purpose (whatever that is) - but these sorts of implementations would be a better fit if axiomatic correctness is what you are asking for.
Anyways... if you can figure out what it is that you want, I guess go for it... --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 15:35, 21 October 2015 (UTC)
:There is always an othonormal basis in a vector space with a scalar product. And the inner product always defines a scalar product. So these are not additional constraints. The only additional constraints I added were the vector dimension of at least five and the euclidean metric.
:I'm not sure where you are going with your suggestion of boolean addition, multiplication or modular arithmetics. I'm pretty sure such operations would not allow the inclusion of a vector space.
:You seem to keep questioning the pertinence of the axioms but again, I did not invent them. They look fine to me.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 15:55, 21 October 2015 (UTC)
::Nothing in the text I quoted requires the existence of a scalar product. You did mention scalar product elsewhere, but not in the quoted axioms. See also: http://mathworld.wolfram.com/VectorSpace.html --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 17:37, 21 October 2015 (UTC)
:::I was referring to your mention of the orthonormal basis being a constraint to the task. The existence of a scalar product, and thus of an orthonormal basis, is a consequence of the axioms. It is thus not a constraint.--[[User:Grondilu|Grondilu]] ([[User talk:Grondilu|talk]]) 19:02, 21 October 2015 (UTC)
::::Sure, all vector spaces have a basis but there's nothing in those axioms that say anything about the dimension of that basis. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 20:46, 21 October 2015 (UTC)
| |||