100X tensor algebra speedup!?!

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.

1 Like

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.

1 Like

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?

1 Like

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 :smiley:


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.


Is there a reason why you’re not creating a monetization process for this? There must be products that can spring out of all the USPs that you know this formalism enables right? Build that and charge for it. I fully understand your situation and the frustration, but no one is going to pay you money for an open source project unless they’re a university or it solves a crucial itch for them. And, as I understand from this thread, people are struggling to understand how this formalism applies to their everyday problems. You’re obviously talented, so use that talent to make your own product or explain to companies and or universities why they should hire you in a better way. Just offering my two cents. :blush:


Well, the README is not intentionally obscure, but it currently leaves out of a lot of information that could be included. This information will not be publicly available until I publish my paper/talk at JuliaCon.

I certainly want to help spread these ideas and concepts far and wide, but I don’t want to do that prematurely before the foundations are solid. I will teach some math, but not the gritty internals of it.

Honestly, I just want to publish a paper and have a stable API before I make huge documentation.

You can pay me at https://liberapay.com/chakravala

And yes, I also want to split this topic.

1 Like

Time to split this topic?


Hi all! I know I’m reviving quite an old thread; so much has happened over the last five years, but I eventually developed a new theory of tensor compilation and wrote a tensor compiler: Finch.jl. It supports much more than just sparse tensors, including run-length-encoding, triangular or padded arrays, block-sparsity, and more! Finch doesn’t use Einstein summation as input, rather it uses full loop nests with statements and if-conditions, so you can do convolutions, scatter/gather, fuse or reorder loops, mask computation, and so on. I remembered this thread and thought you might find it interesting. Let me know what you think!


That’s cool. I think you should write a new post with an intro to your code. Interesting that it eventually wound up in Julia anyway :smirk: