Expression Evaluator in for Scalars

Hi All,

I’m new to GA and learning GA by trying to implement the support for Swift Programming language for the same. I’m using the expression evaluator as a way to evaluate my implementations. I’m having tough time in understanding what should be the correct answers when we try to find inner and outer product of 2 scalars

11 | 12 → Gives 15 (Inner product) // I was expecting similar result as 1112 = 132
11 | 11 → Gives 11. (Inner product) // I was expecting 11
11 = 121

11 ^ 12 → Gives 7 (Outer product). // I was expecting zero here
11 ^ 11 → Gives 0 (Outer product). // This matches my expectation as zero

I’m not finding proper resource on how the Geometric products inner and outer products to behave for scalars? Or it is a bug in the tool? Any inputs will be helpful.


You can try using Grassmann.jl as an evaluator instead, it has a consistent implementation for scalars: GitHub - chakravala/Grassmann.jl: ⟨Leibniz-Grassmann-Clifford⟩ differential geometric algebra / multivector simplicial complex

Those should all behave like regular scalar multiplication, I have also previously given an explanation for the exterior product of scalars Exterior product of grade zero blades

1 Like

Thank you @chakravala

For scalars, the tool interprets the expression in the usual Boolean manner. That is of course unfortunate. But indeed, for scalars the inner product is the lowest grade of the GP, and thus the regular scalar product; and for outer product the highest grade term - which is also the usual producr.
Avoid the beginners mistake of thinking that any geometric product is the sum of inner and outer…


1 Like

Thanks @LeoDorst. Got it. Your talks listed in are really inspirational and motivated me to tryout the GA on Apple frameworks and ultimately build all the examples shown in Ganja.js in the Mac or ios App. I’m speaking ahead of myself now. :slight_smile: . Will keep you all posted in this forum with my progress.

Okay now I have the Geometric product, Inner product and Outer product sorted out in my code.
I’m yet to move things in to a newer git repo to make it public. But here is the draft version.
All the tables results are listed:

Here are all the unittests for each of those cases:

I highly recommend avoiding the 0 index syntax in GA, it’s only going to cause confusion. Indexing in mathematics is not 0-based like it is in some programming languages. Mathematics notation has 1-based indexing, with 1 always being the first index. Your e1 is actually the 2nd basis element. Mathematicians such as myself prefer to have the last basis element square to 0 instead of the first element. Associating 0-based indexing with degenerate metrics is bad notation and the 0-based indexing is inconsistent with how mathematiciand do indices.

People who use 0-based indexing look to me as if they are a bunch of unexperienced people trying to follow some kind of trend, except the trend is stupid and it’s not properly consistent mathematical notation to associate degenerate metrics with 0-based indexing.

Hi @chakravala thanks for your feedback.

Using zero based index is more of a programming practicalities which is followed dates back to when the the computers were invented. We can compare this to how mathematicians use the term “Mathematical convenience” similarly we can say “Programming Convenience” in terms of implementations in a software. This helps to keep the code simple and understandable to people who come from programming background.

This is your personal opinion. I’m not here to pass comments on your personal opinions.

So you will also used 0-based indexing when you use a standard flat metric instead of degenerat merric? If you stay consistent and stick with the 0-based index for all metrics including non-degenerate metrics, then i might respect it, but if you’re associating 0-based indexing with degenerate metrics, then I’m going to disrespect that.

It’s not just an opinion, it’s a matter of making sure that people don’t spread inconsistent notation widely. Unfortunately, the Cambridge people and Stephen DeKenninck keep on perpetuating inconsistencies in notation and definitions, because they’ve already written books that are inconsistent mathematically, they cannot admit it so they keep on pushing inconsistent ideas.