Help with simplified StaticArrays implementation

[chakravala]

@lobingera

Can you qualify or quantify? What makes it ‘too large’ ?

StaticArrays takes about 1 second to load.

AbstractTensors takes 0.1 seconds to load.

The only feature from StaticArrays I need for the entire Grassmann.jl ecosystem can load in 0.1 seconds.

Grassmann.jl loads 2x faster without StaticArrays

Why would I want to wait ~4 seconds to load my packages, when I can cut it to 2 seconds by not depending on StaticArrays?

Also, in Grassmann.jl I can solve a linear system faster than StaticArrays does, so it’s not like I can’t do linear algebra without it. I can do linear algebra without it.

Grassmann.jl A\b 3x faster than Julia's StaticArrays.jl

This was because of a special explicit case for dimensions 1 and 2 and 3, which are now accounted for in Grassmann.jl also. Also, support has been added for Moore-Penrose inverses for underdetermined and overdetermined linear systems. For underdetermined cases, the exterior product algorithm works ~20x faster than the SMatrix algorithm, and it is numerically stable. For overdetermined equations, the method used is based on the traditional normal equations, and this is prone to more numerical i…

So therefore, I want to make Grassmann multi-linear algebra not depend on the big package StaticArrays

@Elrod

Anyway, I think type piracy is also a great reason for chakravala to be interested in defining his own types. That is, he’s likely to want to define his own methods on these arrays that may conflict with the existing methods. E.g., he may want to define his own A \ b method without pirating.

Not quite true, no. While, yes, I do define my own linear algebra methods, I already had my own types for that derived from wrapping SVector. Type piracy was never the issue. The main issue is that depending on SVector is too large of a dependency, because it needs to load all sort of extra things for matrices.

@Elrod

A disadvantage of the current SDTuple approach is that it encodes the statically known information as a tuple , e.g. (3,4) rather than a Tuple type, as in Tuple{3,4} .
Tuples are far nicer to work with, and I grew tired of the boiler plate. But Tuple types let you do what StaticArrays does:

Note that the size in my static variant is always 1 dimensional, I never support higher dimensional arrays, because I can represent those as nested vectors.

So in AbstractTensors there is no Size it is always only a simple length and no other dimensions.

That’s what makes it simplified and different.

@Zach_Christensen

It’s based on the idea that we could probably replace our entire set of dense arrays with something that wraps a linear collection and a tuple of axes.

As you can see, I am in alignement with this approach, since I believe to only construct linear indexing initially, and then matrices get constructed from that later on.

@Elrod

don’t reinvent the wheels you don’t plan on improving or experimenting with, and go through an interface so other unrelated packages can benefit from that static sizing information.

I agree on this, I am only doing this as an experiment, and it is work i’d rather not have to do, but it seems to be making a big difference in load times.