clifford
clifford copied to clipboard
pygae
use unicode?
any thoughts on whether clifford should use unicode characters in it's codebase?
Can you give some examples of function names that might benefit from this? If we go that route, I'd be inclined to create a clifford/unicode.py file that just aliases existing functions.
Or do you just mean in docstrings?
Worth noting that things like def ↑(x): ... are not legal in python anyway
Congrats on py implementation of GA!! re: unicode py IDs :: snippet (works in Spyder, VSCode, and Jupyter):
class ⵛ_test:
''' UNIcode self ⴲ''' # some don't render in #-style comments
def __init__(ⴲ):
ⴲ.i = 0
ⴲ.ⱮL = [
'dummy', 'init', 'get', 'set', 'delete',
'AEC_momma.py running as' ]
ⴲ.Ɱ = {
'INIT' : 'Ɱ __init__',
'GET' : 'Ɱ __get__',
'SET' : 'Ɱ __set__',
'DELETE': 'Ɱ __delete__' }
Ᵽ(ⴲ.Ɱ['INIT'], end='|')
def __set__(ⴲ, i, value):
Ᵽ (ⴲ.Ɱ['SET'], end='|')
ⴲ.value = value
def __get__(ⴲ, i, owner):
Ᵽ (ⴲ.Ɱ['GET'])
return ⴲ.value
def __delete__(ⴲ, i):
Ᵽ (ⴲ.Ɱ['DELETE'])
del ⴲ.value
def move(ⴲ, x, y):
ⴲ.x = x # uni char 1-per-line
ⴲ.y = y # avoid ;-concat here
def reset(ⴲ): ... .
PEP supports this; caveats concern mostly "letter-like character" from UNICODE. Intending on replacing Bivector base IDs with single-char UNICODE. s.a.m.
caveats concern mostly "letter-like character" from UNICODE.
This is indeed what I was alluding to in my comment above - the PEP you refer to is https://www.python.org/dev/peps/pep-3131/, thanks for reminding me to search for it.
I'm not sure what the rest of your comment is trying to demo(beyond perhaps your favorite unicode characters :) )
Snippet adapted from my 3.8.0 abc experiments, as sanity check for if "pseudoConst" 'self' could be a unicode char (it can be), toward project idea of replacing G3 basis bivectors { e12, e23, e31 } with sth like { ⊖, ⊘, ⊙ } • Goal is spherical rotation using the even subalgebra of Cl(3), which needs only 4 parameters, just like quaternions. Project goal is GA CS transform, spec. EQCS to GCS. Absolutely fascinated with your [clifford] package!
Whereas PEP 3131 laudably allows Unicode identifiers, its scope could only skirt recommended usage, which seems scarce anyway. Unicode poses risks: Services such as GIT, and python metacompilers (JITs, e.g.) would be (and are) impacted indirectly non-ASCII characters. Advantages are well known, but do they suit coding? How, why? Python will allow ⊖⊘⊙ for the 3D Bivector set. But is it worth it? Such novel "uniglyphs" can suit printed notation. But coding? G3+ signs to 4-param, dual to Q, and should scan as (1,⊖⊘⊙) Visualization may seem trivial, but for me is prioritized, as GA adopts notation, quarantined experimentally for now. s.a.m.
Again, I'm finding it somewhat hard to follow your comment.
Are you talking about using Unicode in the source code, as the names of the basis blades? Or suggesting that we use it in __repr__?
Note that we're not limited to a textual __repr__ - we could add a _repr_latex_ if we felt it was useful.
Yes, I would wish the basis 2-blades in G3+ might be given new symbolic representation, since the three bivectors making that basis are new objects, not just orthogonal vectors. But logically there is no difference between e12 (ASCII) and some other (Unicode single-char) identifier, only a symbolic difference, of debatable merit (I advocate the merit). Therefore, knowing that ASCII is always safe for coding, the introduction of unicode characters must be criticized as an unwarranted risk, due to services linked to the pythonic environment, such as GIT and JIT "readers", succeptible to unanticipated, though allowable, unicode chars, simply in trying to parse the code. I think literature calls that a "round trip" service. Also, not all Unicode is usable, some characters "behaving" unpredictably. That theoretically can be strictly controlled, but such adds to overhead. If I were responsible for advisement, I'd counsel against Unicode in production code, except, as you very wisely suggest, they might be in string form, e.g. in repr, although, even then, I would expect them to "be noticed" unexpectedly later, and again would caution against using them. This, though I would prefer them for valid reasons. But code "security", or really pythonic environment stability, is key, and Unicode is not standardized "pythonically" beyond the interpreter.
Good heavens, my comments surely must seem "out of the blue." I am currently using [clifford] to reverse-engineer your logic in implementing GA, so I can build a subset of GA for 3D rotations. Python is ideal for GA (my opinion), and [clifford] is the best. Enormous benefits come from the Conformal Model, but I am a humble astronomer trying to enable GA rotation for a very simple Coordinate System transform (to Galactic), which I want to be visualizable through GA, hence the symbology. I do intend to use three Unicode chars for e12 e23 and e31. But all I need is 4 of the 8 basis coefficients in G3 to do this. It was just by chance I noticed arsenovic's open-ended question about Unicode, the same day I set up a repository on GitHub. Congratulations on your work, of enormous significance!
- s.a.m.
I'll emphasize that I don't think you want to do this, but if you did you can in master now use:
import clifford as cf
layout = cf.Layout([1, 1, 1], ids=cf.BasisVectorIds(['⊖', '⊘', '⊙']), names='')
which gives you
>>> layout.blades
{'': 1,
'⊖': (1^⊖),
'⊘': (1^⊘),
'⊙': (1^⊙),
'⊖⊘': (1^⊖⊘),
'⊖⊙': (1^⊖⊙),
'⊘⊙': (1^⊘⊙),
'⊖⊘⊙': (1^⊖⊘⊙)}
Superb. You are very kind.
Unicode identifiers are surely an eccentric idea, but I had to try it. As you show, it does work. (but...).
I've accomplished my CS transform rotation using [clifford] G(3+) even subalgebra in Jupyter,
but now Dorst et al. and Hestenes et al. have me hooked on Conformal model,
so my gitHub uploads are simply not ready. Just some DMS/HMS parsing, and the GA rotor.
but all credit must go to your team, which has done astonishing work. I just need Galactic transform.
This will make the 8th method I've employed for EQCS-GCS transform, this being Cl(4,1),
but Euler, Axis-Angle, Matrix, Quaternion, and even trigonometric-direct (which nearly killed me)
are completely overshadowed by GA, which is some kind of breakthrough miracle.
Currently transliterating CGA examples from Dorst's (C++) GAViewer script to clifford python.
I'm new to gitHub, so if I'm out of line here, just warn me away. Great work you all!!
