Dueling Duals: PGA code vs evaluator

Projective GA
1

I’m playing with my own PGA implementation, and I’m getting some confusing results trying to debug basic parts. Most critical seems to be the dual operator. The python and cpp code generated by the site flips the order of the multi vector coefficients, and uses the same basis order as the PGA cheat sheet. The Expression Evaluator seems to use something different, producing sign changes in grade 1 elements:

!(1+e0+e1+e2+e3+e01+e02+e03+e12+e31+e23+e021+e013+e032+e123+e0123)

= 

1-e0-e1-e2-e3+e01+e02+e03+e12-e13+e23-e012+e013-e023+e123+e0123

The different basis elements in the output suggest the evaluator is using e13 instead of e31, for example, but I still can’t quite reconcile that with all the grade 1 sign changes. Perhaps I should be requesting a way to control the basis element set/order.

2

The dual is defined on the basisblades x so that x*x.dual = pss. This is independent of the chosen basis (i.e. for both e13 and e31)

Cheers,

Enki

1 Like
3

If you’re getting bugs implementing the complement operator because you used enkimute cheat sheets and code, then you are inheriting the bugs from enkimute. What he’s teaching you there is not the mathematical correct definition, as his definitions don’t satisfy the necessary axioms for a Hodge complement to be mathematically correct, the sign will be incorrect. That code and the cheat sheet are not the mathematical correct definition of Hodge complement used in differential geometry. Enkimute’s definition is some incorrect definition that’s easier to explain i guess, but that doesn’t make it correct.

The correct definition compatible with the original Grassmann complement and Hodge-DeRahm differential geometry is (\sim x)I, which will give the correct sign unlike enkimute’s cheat sheets/code.

Here is the correct result:

julia> using Grassmann; @basis D"1,1,1,0"
(⟨1,1,1,0⟩, v, v₁, v₂, v₃, v₄, v₁₂, v₁₃, v₁₄, v₂₃, v₂₄, v₃₄, v₁₂₃, v₁₂₄, v₁₃₄, v₂₃₄, v₁₂₃₄)

julia> julia> !(v+v4+v1+v3+v3-v14-v24-v34+v12-v13+v23-v124+v134-v234+v123-v1234)
-1 + 1v₁ + 1v₂ + 1v₃ + 1v₄ - 1v₁₂ + 1v₁₃ + 1v₁₄ - 1v₂₃ + 1v₂₄ + 1v₃₄ - 1v₁₂₃ + 2v₁₂₄ + 1v₂₃₄ + 1v₁₂₃₄

I’ve been explaining for years now that enkimute is implementing and describing incorrect methods in his cheat sheet and code, and it’s not some mystery bug, it’s very clear what the mistake is and has been explained several times. I assume it’s academic ego or something holding them back, I don’t really know though.

4

Using x*x.dual=pss to find a dual, i find that I need to negate the grade 3 coefficients before reversing the order. This matches the result of the pga3d.hpp regressiveproduct operator and also results from the dual and undual operators on a homemade meet operator.
I’m beginning to suspect that my ‘bug’ is a conceptual problem on my part. I worked out a formula for a multivector line between 2 input 3D locations, for a convenient constructor and sanity check.
My result, a line from (xa,ya,za) to (xb,yb,zb) can be written:

e12(za-zb) + e31(ya-yb) + e23(xa-xb) + e01(zayb - yazb) + e02(xazb -zaxb) + e03(yaxb - xayb)

But the 2 join operators disagree the sign of the e31 element with the result of the above. Am I looking at the same line going in different directions or something that otherwise not a bug?

5

I don’t understand your note.

The usual definition is “I” = e1234. In PGA, e4*e4 = 0. If x contains e4 as a factor, then it seems that (~x)I = 0.

Or is there something I don’t understand about your notation?

6

@Pixelsplincher, in 3D the trivectors indeed get a minus when dualized. This setup makes sure that when you generate a translator ‘along’ a line using e^{\mathbf e_0 L \mathbf e_0^*} you get the same direction nomatter how many dimensions you are in. This enables a dimension-agnostic approach - my own pet-peeve (see the SIBGRAPI videos)

@doc_placebo, the comments given by Michael Reed - @chakravala are not self-consistent and you’ve correctly noted that his formula and example do not match up. Since he was banned by me from the bivector discord for repeatedly insulting others he’s been more focused on trying to discredit me than anything else. (up to the point he has emailed the prominent researchers in the field trying to discredit me - a footgun if I’ve ever seen one :wink: )

The choices made in my ganja.js library are in the mindset of aligning to the existing literature - they are not ‘by me’ - I would not want to take any credit on work I have not done.

@chakravala - you have exhausted your warnings with your behavior on the bivector discord - if you use this forum to insult or discredit others there will be no warnings past this one.

Cheers,

Steven

7

I was using e0 as the null blade, rather than e4.

8

Yes, I prefer to use e0 as well. I was trying to respond to chakravala, who was using e4 instead of e0 (I think), and came up with a seeming contradiction. I’ve seen the reply by enki as well.

I have been working on a symbolic interpretation package for PGA (also works for CGA and any signature up to 6 dimensions). For the definition of dual (and undual) I have been relying on “A Guided Tour to the Plane-Based Geometric Algebra PGA” by Leo Dorst & Steven De Keninck, version 2.0, March 2022, https://bivector.net/PGA4CS.pdf.

For what it’s worth, here is an output that shows how I define Dual (newlines added for clarity):

Map(x, _bases, (x, Dual(x)))
=> ((1, e0123),
(e0, e123), (e1, -e023), (e2, e013), (e3, -e012),
(e01, e23), (e02, -e13), (e03, e12), (e12, e03), (e13, -e02), (e23, e01),
(e012, e3), (e013, -e2), (e023, e1), (e123, -e0),
(e0123, 1))

9

For simple symbolic calculations in PGA, I have an experimental setup here : https://enki.ws/ganja.js/examples/coffeeshop.html#cRMKujIfi&fullscreen

For non-degenerate signatures, the duality operator is defined by most authors simply as division (dual) or multiplication (undual) with the pseudoscalar.

Cheers,

Steven.

10

Yes, well obviously ! is the identity metric version of the complement operation, so its not 0.

If you are serious about mathematical formalisms and axiomatic foundations, unfortunately Enki and the Cambridge people are using incorrect mathematics. It might be good enough for shoddy graphics programmers to ignore inconsistencied caused by lack of rigor, but its not good enough for very serious mathematical reasoning based on axioms.

So if you’re running into inconsistencies with their work, that’s because there really are inconsistencies in their work related to issues of orientation. I could elaborate further, but since you’re probably not serious mathematicians its not worth it.

11

The usage of e4 instead of e0 is a demonstration of the fact that PGA is inconsistent with automatic differentjation. It shows that the signs of “differentiation” are dependent on the ordering of the basis, which is inconsistent with the axioms of differential operators.

If a correct formalism was used for differential operators, like the one I have introduced before, then you would avoid the inconsistencies of PGA, and it also would be unnecessary to use degenerate metrics.

Anyway, this whole Enki PGA thing is riddled with various inconsistencies, which Enki of course always responds to with some kind of gossippy personal attacks against me, as if gossip about me has anything to do with mathematical axioms ahaha.

12

Well, good luck surrounding yourself with yes-men, who aren’t allowed to point out inconsistencies which discredit some aspects of your work. The only person you are harming is yourself and your followers, because the people making the criticism are the ones who have insight you are not willing to open yourself up to.