galgebra
galgebra copied to clipboard
incorrect definition of reflect_in_blade?
The definition of reflect_in_blade does not look correct at:
https://github.com/pygae/galgebra/blob/2b888f8dacae72ee9c7770a1e7671d7f693e1610/galgebra/mv.py#L419-L423 Assuming pure blades, it gives a positive result if grade*(blade_grade +1))
is even, and negative if grade*(blade_grade+1)
is odd.
However, if we take the simple example of a vector v1 reflected in a vector v2, each of them unit vectors in a geometric algebra with all positive norms, we should get v1.reflect_in_blade(v2) = -v2*v1*(v2)^-1 = -v2*v1*v2= v2*v2*v1 = v1, and -v2*v2*(v2)^-1 = -v2*v2*v2 = -v2
, i.e., the sign should be negative, as described in the wikipedia page: https://en.wikipedia.org/wiki/Geometric_algebra#Reflection, so that reflecting a vector through itself gives minus the vector, and reflecting a perpendicular vector through itself has no effect.
However, in this formula, for a blade, grade_dict[blade] is just the grade of the blade, so code gives grade * (blade_grade + 1)) % 2 == 0 ==> 1*(2)%2 == 0
, leading to a positive sign in the formula for reflection of a vector in a vector, the opposite as what the standard definitions would give.
The documentation here also gives the same formula. https://galgebra.readthedocs.io/en/latest/generated/galgebra.mv.html#module-galgebra.mv
I'm not 100% what the correct formula should be. The product of an odd number of vector reflections is odd, and even number of vector reflections is even according to that wikipedia page, so:
(odd)*(even)*(odd)^(-1)
-> should be positive (mod signatures)
(even)*(even)*(even)^(-1)
-> should be positive.
(even)*(odd)*(even)^(-1)
-> should be negative.
(odd)*(odd)*(odd)^(-1)
-> should be negative.
So this would imply the logic should be something like:
(2*blade_grade + grade)%2 == 0:
positive
(2*blade_grade + grade)%2 != 0:
negative
Thanks for the report. That function looks suspicious to me, and seems to be crying out for a grade involution function (#121). At a glance, I'm not sure what the correct behavior is, but it shouldn't be too hard to decide.
Note that (2*blade_grade + grade)%2 == 0
iff grade % 2 == 0
Note that (2*blade_grade + grade)%2 == 0 iff grade % 2 == 0
So, looking over wikipedia (no citations, but proof seems OK), then it would be.
A -> M alpha(A) M^(-1), where M is a versor, A multivector, alpha() is the automorphism of reflection through the origin. For A = vector, this is A->-A, For scalar, it's A->A, so for these yes, it's (-1)^(grade(A)). For a bivector, then it seems like reflection through the origin should give A->A, since (-e1)(-e2) = e1e2? So it would just be (-1)^grade(A) in the general case? I am getting myself confused. Is there a canonical reference to check?
Was there ever a resolution to this? Is there something I can check/verify?
Perhaps ~~@enki~~ @enkimute can comment on what they think the correct signs are here. Largely this comes down to convention, and I think the "correct" choice depends not only on who you ask, but when you ask them
5+5=10 seems to mostly hold true. Also not sure why I’ve been tagged here
On Mon, Dec 13 2021 at 12:44 AM, Eric Wieser < @.*** > wrote:
Perhaps @enki ( https://github.com/enki ) can comment on what they think the correct signs are here. Largely this comes down to convention, and I think the "correct" choice depends not only on who you ask, but when you ask them
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/pygae/galgebra/issues/470#issuecomment-991994961 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAAHFY6FNE6S6MIL3EESLBTUQUXWDANCNFSM4YLRNZAQ ). Triage notifications on the go with GitHub Mobile for iOS ( https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 ) or Android ( https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub ).
I'm not entirely sure how it's convention? It seems like, according to the wikipedia page, that reflecting a (positive sign) basis vector in itself (plane orthogonal to itself) should give (-1)^1*e0*e0*e0^-1 = -e0
, not (-1)^(2)e0*e0*e0=e0
. Is there an alternative definition of reflection? If there is a convention that the wikipedia page is adopting, shouldn't one be able to choose which convention to use?
Sorry, I meant @enkimute!
Anything else I can do here?
ok, so,
If you ask me today, I'd say there's two solutions that are equally valid. It depends on the interpretation of the term 'orientation'. Turns out there's two perfectly valid ways to consider orientation of geometric elements.
One one hand we have an intrinsic orientation - In this case the sign of a homogeneous multivector is used to denote orientation within the subspace of the element. (e.g. one way or the other along a line, clockwise or counterclockwise in a plane). On the other hand we have extrinsic orientation - in this case we interpret the sign as denoting an orientation of the subspace in its embedding space. (e.g. clockwise or counterclockwise around a line, one or the other side of a plane).
Unfortunately, when asking around, I've discovered most people's intuition uses one type for lines (intrinsic, along them) and another type for planes (front/back, extrinsic). As you can see in the image, both types reflect differently (blue elements are the original, purple is reflected in a parallel mirror, cyan is reflected in an orthogonal mirror). When one type needs a minus sign, the other doesn't.
In general for an extrinsic orientation, you get for reflecting a hyperplane b in a hyperplane a -aba
. For intrinsic orientation you get aba
.
Extending using the outermorphism we find for extrinsic orientation : -1^{rs} aba
where r
is the grade of a
and s
is the grade of b
. For intrinsic orientation we get aba
- no minus signs needed.
Unfortunately, I couldn't find any references recognizing this difference (although there's papers in both camps. nobody seems to have put it together). My own writeup on it is not yet finished.
Happy to have added to the confusion.