chakravala / Grassmann.jl

⟨Grassmann-Clifford-Hodge⟩ multilinear differential geometric algebra

Home Page:https://grassmann.crucialflow.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Using SymPy scalars + python, ganja interoperability

moble opened this issue · comments

I see that you've made it possible to use REDUCE for symbolic manipulations, but I was hoping to be able to use sympy. I tried the obvious thing:

using SymPy, Grassmann
@vars x y  # This defines x and y as SymPy.Sym objects
@basis^3
x*v + y*v12

But the last line causes an error:

ERROR: setindex!() with non-isbitstype eltype is not supported by StaticArrays. Consider using SizedArray.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] setindex! at /Users/me/.julia/packages/StaticArrays/mcf7t/src/MArray.jl:134 [inlined]
 [3] setmulti! at /Users/me/.julia/dev/Grassmann/src/algebra.jl:31 [inlined]
 [4] +(::SValue{⟨+++⟩,0,v,Sym}, ::SValue{⟨+++⟩,2,v₁₂,Sym}) at /Users/boyle/.julia/dev/Grassmann/src/algebra.jl:796
 [5] top-level scope at none:0

I tried various other combinations, and it seems that whenever the sympy scalars multiply different Grassmann basis elements, this error occurs. But even if they multiply the same basis element, something weird happens:

julia> (x*v1) + (y*v1)
x + yv₁

This sentence from the README

By default, the coefficients are required to be <:Number.

suggests that is should work right out of the box, because

julia> SymPy.Sym <: Number
true

I also tried

Grassmann.generate_product_algebra(SymPy.Sym)

and

Grassmann.generate_product_algebra(SymPy.Sym,:(SymPy.:*),:(SymPy.:+),:(SymPy.:-))

to no avail.

I'm sorry that my julia skills are insufficient to let me figure this out, but this is my first day with this language (being attracted mostly by this exciting package). I would appreciate any help you can give.

Indeed, the error you got

ERROR: setindex!() with non-isbitstype eltype is not supported by StaticArrays.
Consider using SizedArray.

says it all, as in you must consider using a SizedArray

the same issue applies to the REDUCE algebra also, which is why I had to define extra methods in

https://github.com/chakravala/Grassmann.jl/blob/master/src/symbolic.jl

there I have defined the required methods to support SizedArray elements with arrays, however it is currently designed to work with the Reduce package and has not been tested with SymPy yet

currently I am working on a new branch where I am implementing LinearAlgebra.UniformScaling to be interpreted as a generalized pseudoscalar element independent of any VectorSpace, so after I finish that work I might be able to look at compatibility with SymPy, but you are welcome to keep trying it yourself and ask further questions on here

I suspect one of the main issues is that since it is <:Number it is not being placed into SizedArray automatically, because I have <:Number set to not use the SizedArray, unlike Symbol and Expr.

this particular package is not necessarily a good starting point for first learning the Julia language, so I hope this does not ruin your overall impression if it is too difficult

have you tried using the Reduce package for your symbolic compuation needs? I find that it better suits my needs for use in the Julia language (since I'm also the creator of it, and I made it to suit my needs)

for example, the print output of symbolic coefficients of tensor terms with Reduce is handled correctly with the correct parenthesis, because it is detected as Expr and Symbol but for SymPy no such feature has been added yet to support it yet

in the future, I intend to add a feature which converts a symbolic multivector element into a fast function

Speaking of using SymPy, another range of possibilities includes some type of interoperability with the other python geometric algebra modules, such as clifford, galgebra, pyganja, and ganja.js.

Although I have starred some of those packages, I am actually not very familiar with their usage, and would like to leave this topic open to comment by @arsenovic @hugohadfield @enkimute @brombo

Perhaps, there is some kind of interoperability desirable or possible, especially for the graphics visualization (as mentioned by @drjrkuhn) or perhaps the symbolic computation mentioned by @moble

Julia happens to have a lot of interoperability with python in place already to begin with.

Hi @chakravala
So far I have held off from commenting on this library as I am neither a mathematician, nor a physicist, nor a Julia programmer and was a little out of my depth!
Generally I have heard that Julia and python have good interoperability and Julia has definitely been on my radar since its inception but so far I haven't had the time or requirement to get stuck into it.
Clifford is built on a very simple but (for high dimensional algebras) inefficient memory model, a flat, dense, array of multivector coefficients. While this likely impacts its performance when operating with high D algebras it makes it very easy to interface with other things and (without looking at the code here) I imagine that it should be fairly ok to interface with most things (there is a clifford tutorial presentation here if you are interested in the library). galgebra has very similar syntax to clifford, @utensil is the expert on galgebra, I confess I barely use it at the moment but it is pretty mature and seems very feature rich.

For visualisation currently pyganja will be able to help if you want to visualise things in (4,1) ie. (++++-) according to the CGA model. As data it takes 32 dimensional arrays of floats/doubles and pipes them straight through to ganja.js with a bit of boilerplate thrown over the top to make it render correctly. Ganja.js itself is much more potent than the functionality that pyganja exposes so if you fancied helping out on expanding its interface that would be greatly appreciated, currently I have only focussed on the conformal model as that is the space that I do most of my research!

I think one of the most promising and simplest ways of achieving interpoerability of the various packages is via a numerical multivector file format of some sort, currently clifford uses a (basic and in need of extension for higher dimension algebras) file format as discussed here: pygae/clifford#61 and implemented here https://github.com/pygae/clifford/blob/master/clifford/io.py
I think it is likely I will add functionality to pyganja to be able to directly load and visualise multivectors in this file format...

Maybe worth playing around with making some kind of bridges between these libraries, at least just for testing purposes if nothing else... what do you recon?

interoperability between galgebra and clifford has been discussed before ( i cant find where) . the problem is that the symbolic and numerical packages are so different its hard to see how this would work except for simple cases. actively maintaining this would be a lot of work.

however, i think keeping the syntax as similar as possible is a great idea, because why not. hugo's idea to use 'IO as a bridge' i think is the way to go.

also i think using ganja.js as the universal GA viewer would be good.

interoperability between galgebra and clifford has been discussed before ( i cant find where) .

It was the discussion started here: https://github.com/brombo/galgebra/pull/15#issuecomment-422078547

@moble this should be working on the master branch of Grassmann right now

julia> using SymPy, Grassmann; @basis^3
(⟨+++⟩, v, v₁, v₂, v₃, v₁₂, v₁₃, v₂₃, v₁₂₃)

julia> @vars x y
(x, y)

julia> x*v + y*v12
x + (y)v₁₂