Catlab.jl VS StaticArrays.jl

Related to this, AlgebraicJulia has been doing a lot with applying concepts from algebra and category theory to data analysis and modelling.

https://www.algebraicjulia.org/

There's some blog posts that are also interesting:

https://blog.algebraicjulia.org/

> Maybe I’m just too bitter about academia in this point in my career but it seems like we’ve run out of things to study and/or have too many people doing it.

We have certainly not run out of things to study, but I think we've hit the limit on what can effectively be communicated through traditional science journals [1], and we need to address the reproducibility crisis through open source science and reconsider the incentive structures around academia [2]. We need to oppose initiatives from people like Bill Gates who wish to privatize science through his various non-profits, as knowledge works better as as commons (we were unable to deal with the pandemic partly because Bill Gates prevented Oxford from open sourcing their work on COVID [3]). We need software that can compose scientific models [4], and organizations that can facilitate greater coordination among scientists. Science will become all the more important in an increasingly uncertain world, but are we up to the task?

[1] https://www.science.org/content/article/frustrated-science-s...

[1] https://numfocus.org/open-source-science-initiative-ossci

[2] https://www.wired.com/story/opinion-the-world-loses-under-bi...

[3] https://www.algebraicjulia.org/

Thank you for replying, but what prevents you from releasing your code? Dr Rydeheard has shared the StandardML version from his book (and the book). Of course if you don't want to share your code that is your prerogative and that is fine, but I am just trying to understand the issue that is preventing you a little more clearly. My interest in your implementation is strictly one of personal education. With applied category theory becoming more popular and computing implementations often used for teaching purposes (e.g. this book ) I would like to see a lisp implementation. It is built into Haskell, mostly, and people are developing libraries for Idris and Julia. I would find it instructive to see the implementation in common-lisp. Thank you for taking the time to respond to my original question.

The biggest group outside of numerical computing in Julia land are the PL and systems people though? This includes type theorists [1], database folks [2], distributed systems people ([3] to name just one). There are also a fair number of compiler nuts, hence the existence of multiple projects [4][5] in this space. And this is before getting into things that bridge more than one of the domains above, e.g. [7] or [8].

FTR, I think it's fair to question whether numerical computing should have an outsized influence on the direction of the language. I also think it's a pretty fair comparison to point out how standardized and consistent the Rust governance process is compared to Julia's (the Rust RFC system is an exemplar here). That doesn't mean there is a dearth of PL and systems knowledge in the Julia community though.

[1] https://github.com/AlgebraicJulia/Catlab.jl

Performance is already 100 times faster than Sympy, but I was running into slowdowns computing the adjugate of the matrices I'm working with. I turned to the StaticArrays.jl module, which did speed up performance, but threw an error at me when the matrix in question went from a 4x4 to a 5x5. Here is the code used to generate the matrices:

I know this is the Rust subreddit, but I have to ask if you considered Julia? It seems purpose-built for what you're trying to do. It has built-in multidimensional arrays which are significantly more ergonomic to use than either Python or Rust, and because of the way the type system works there are tons of specialized array types you can use with optimized operations (and writing your own is quite easy). In particular you might be interested in StaticArrays.jl which if your arrays have a known, small size at compile-time can give a massive speedup by essentially automatically doing many of the optimizations you did by hand. They show a 25x speedup on eigendecompositions for a 3x3 matrix on their microbenchmark.

Use StaticArrays.jl instead of the built-in Array whenever you need some statically sized array/matrix.

2. Persistent data structures as found in most FP languages.

Note how neither of these capture the large, (semi-)contiguous array types used for most numerical computing. These arrays are only "easier to optimize" if one has a Sufficiently Smart Compiler to work with. Here we don't even need to talk about Julia: the reason even Numba kernels in Python land are written in a mutating style is because such a compiler does not exist. You may be able to define something for a limited subset of programs like TensorFlow does, but the moment you step outside that small closed world you're back to needing mutation and loops to get a reasonable level of performance. What's more, the fancy ML graph compiler (as well as Numpy and vectorized R) is dispatching to C++/Fortran/CUDA routines that, not surprisingly, are also loop-heavy and mutating.

Should Julia do a better job of trying to optimize non-mutating array operations? Most definitely. Is this a hard problem that has consumed untold FAANG developer hours [2] and spawned an entire LLVM subproject [3] to address it? Also yes.

> The iteration protocol can be made more memory-efficient for large collections and simpler...

Yup, this has been a consistent bugbear of the core team as well. The JuliaFolds ecosystem [4] offers a compelling alternative with fusion, automatic parallelism, etc. in line with that blog post (which, I should note, is a much different beast from Rust's iterator interface/Rayon), but it doesn't seem like the API will be changing until a breaking language release is planned.

> In general, systems languages don't make language decisions lightly. They have committees, discuss how other languages do things, make proposals. This allows more perspectives on each decision. That would be an improvement over the more ad-hoc style of Julia development, as long as Julia can avoid adding every possible feature, which is a risk of expanding the decision-making body.

I'd argue this is a property of mature, widely used languages instead of systems languages. Python, Ruby, JS, PHP, C# and Java are all examples of "non-systems" languages that do everything you list, while Nim and Zig (note: both less well adopted) are examples of "systems" languages that don't have such a formalized governance model.

Julia (along with Elixir) are somewhere in between: All design talk and decision making is public and relatively centralized on GitHub issues. There is no fixed RFC template, but proposals go through a lot of scrutiny from both the core team and community, as well as at least one round of a formal triage (run by the core team, but open to all). Any changes are also tested for backwards compat via PkgEval, which works much like Crater in Rust. There was a brief effort to get more structured RFCs [5], but I think it failed because the community just isn't large enough yet. Note how all the languages with a process like this are a) large, and b) developed it organically as the userbase grew. In other words, you'll probably see something similar pop up when the time savings provided by a more structured/formal process outweighs the overhead of additional formalization.

[1] https://github.com/JuliaArrays/StaticArrays.jl

If you want to lift your value into the type domain, you may be able to use value-types, like Val(2). If you are interested in seeing how to use value-type parameters efficiently, https://github.com/JuliaArrays/StaticArrays.jl does that to great effect.