@chakravala well, in that language, does Grassmann.jl make it possible to contract 3 sparse bivectors in a single kernel? My guess is that @mohamed82008 is definitely willing to learn about multivectors provided that they solve his problem.

No, I haven’t investigated doing operations on 3 elements with Grassmann.jl, but it should be possible.

My post was a general response to to the entire topic, not to @mohamed82008 specifically btw

Well, my problem is more complicated than multiplying 3 sparse matrices. It’s a reduction of 4-6 1st, 2nd and 3rd order sparse tensors to a 1st order dense tensor or a 2nd order sparse tensor. And obviously any package that I use should be able to represent a 3rd order sparse tensor to begin with. If you have some tutorial or example with more than 2 operands, I would be interested to learn your package’s paradigm.

For associative operations such as tensor products and its duals, it would be fairly trivial to make them n-ary. Non-associative operations such as contractions are already kernelized for 2-inputs (contractions are composite operations based on sparse tensor products and the Hodge duality). There can be both a left contraction and a right contraction, and is not in general symmetric unless the arguments are of the same grade. Thus, there would be more complication and effort with kernelizing operations involving contractions, but it should also be possible. The entire package is already built on the concept of building composite tensor operations, and for unary and binary operations this principle is already applied. The same can be done for more complex multi-argument operations, but would require more coding first.

At JuliaCon 2019 I will publish a background summary paper along with my presentation, which will explain the theoretical foundations of Grassmann.jl, which is still a work in progress and I will definitely consider adding more kernelized tensor operations, as that is what this package is built for.

I don’t want to be rude here, but I’d be shocked if Grassmann.jl can rival the speed of something like TACO and I think saying that Grassmann is ‘somewhat similar’ to TACO is perhaps misleading.

TACO is a very intensive tensor compiler system that is designed to look at arbitrary sparse tensor contractions and use also sorts of numerical analysis techniques to lower that to highly efficient kernels. The sensational ‘100x tensor algebra speedup’ in the title comes from the fact that TACO is able to be very clever about lowering a given contraction to code that involves the fewest possible operations. Many of these contractions if done in the wrong order can have completely difference scaling behaviour so it’s important to optimize the contraction order using all sorts of heuristics.

Is Grassmann.jl doing that sort of analysis? Are there plans for doing that sort of analysis?

Well, I’m actually not making the claim that Grassmann.jl competes with taco…

Grassmann.jl does very similar things, but probably goes about it in a completely different way. In my package I use sub-algebras on manifolds, which are cached using combinatorial principles. There are still lots of improvements possible for working by leveraging sparsity, but it is essentially the same type of thing that you are talking about with taco.

Hey, I’m just a single person making this thing completely on my own, it’s just my own playground and how I want my tensor algebra to work, which is based on a different way of thinking for foundations.

Grassmanian.jl looks quite nice and you are right to be proud. I’d add some examples of “applications” to demonstrate how this abstract formulation “adds value”.

Differential Geometry is a topic that’s oversold: most PDEs are 3D at most and so it’s never been clear to me why differential forms are any better than `div`

and `curl`

. So any negativity is because of this underlying context, don’t take it personal. Doing the extra effort of making real world examples will help address that.

As a counterpoint, Taco is much clearer what it does and why it might be useful, and I don’t have to learn what a “multivector” is.

The divergence and curl can be generalized using an exterior differential operator and a boundary operator, which is unified by De Rahm co/homology. This will all be detailed at my JuliaCon paper/talk. In fact, you can easily do those calculations with Grassmann.jl, but I am still working on my paper and implementation designs.

The documentation of Grassmann.jl is intentionally obscure, it is intended to attract people who are willing to go on an adventure (in which they are required to change their foundational understandings).

When it is more complete and stable in design, I will be making more tutorials and applications like PDEs. At that point, documentation and accessibility increases.

I know. What I don’t know is what it tells us that we don’t already know in 3D. Sure, it lets us generalise 3D differential geometry to N-D, but why is this useful?

In conformal field theory, an R^n dimensional manifold is usefully embedded into a higher dimensional space with an additional Minkowski plane. This allows the usage of symmetry and Lie groups to help linearize otherwise difficult problems. For example, you could consider the Navier-Stokes or Maxwell equations embedded in a 5D conformal field theory, also a basis for differential forms.

Let me add a very concrete application of higher-dimensional differential geometry (though maybe you know about this one already @dlfivefifty): The complete description of electricity and magnetism is given by the Maxwell equations. These are greatly simplified by using 4-dimensional differential geometry.

Instead of considering the electric and the magnetic field as two separate 3-dimensional entities, you consider them a single 2-form in 4-dimensional space. It then reduces to a single equation and, even better, this immediately explains why they are so closely intertwined and why what’s an electric effect to one observer can be a magnetic effect to another.

This is very concrete – it’s the kind of physics that makes GPS tick.

Do you mean Special/General Relativity?

Or for ultra realistic ray tracing…?

Yes, Maxwell equation will be reduced to a single equation, many equations are unified by the Hodge DeRahm Laplacian and the quadratic Casimir, so you only need a single operator for “relativistic wave equations”

Also ray-tracers, the best one is currently ganja.js, the author of it has encouraged me to also make a ray tracer.

Hah the ganja.js “wedge game” is super cool.

This too: Algebra vs Geometry - battle 1 – Enki's blog – Math, Graphics, Programming., it’s just a pity about the javascript syntax. Maybe Grassman.jl is the solution to that part

FWIW, statements like this would make me steer clear of a package.

It’s not my responsibility to teach the basics of math to random people. The documentation will be increased when I am done constructing the foundations. Why would I document something that is going to change? Why should I care whether you can use my package?

Please pay me, if you want me to be a teacher.

I have given my source away for free, support is not free unless it is for critical bugs or a problem for me.

And it will become easier to understand when more time passes and the foundations are fully solid.

I see your point and we definitely appreciate you sharing the source code. But documentation can get more people into the package and can increase its value to the users and possibly the developer as well if a lot of users get interested in the package and/or if an interested user has a deep pocket. Of course, the timing of getting these docs out is completely up to you. For example, if Julia had obscure docs, then many of us wouldn’t probably be here.

I think the fact that you advertise the project seems to indicate that you’d like people to use it, and I think that’s where the feedback is coming from (it’s easier to use if the documentation is accessible instead of intentionally obscure).

I think you misunderstood something.

I am not asking you to provide any kind of instruction, I was merely commenting on your practice of making documentation **“intentionally obscure”**.

I don’t really see the purpose of this — no one is obliged to provide documentation, but to invest time in it and then make it intentionally difficult sounds like a waste of effort. I find this puzzling.

The tone of your reply has served to reinforce my earlier conclusion about your package.