I quickly realized it was approximately 20,000 ft over my head, but I still power through these sort of things to see if anything "sticks".

So far, nothing but I'll keep trying ..

Maybe someone else can summarize more accurately or do a better job but I'll take a shot:

The Jacobian often appears in the final segment of a three part calculus series when exploring chain rules and variable transformations. Look up the Jacobian used in converting between x,y,z and spherical coordinates ρ,φ,θ and note its matrix structure. Skimming your Medium Lobosi article it seems it emphasizes this aspect.

The Jacobian also serves another purpose. As stated in the OP's article "The Jacobian operator Df:x⟼Df(x) is a linear map which provides the best linear approximation of f around a given point x."

We like approximations, we can make a speed vs accuracy/memory trade off, you only have so much space in a register or memory cell, and trying to get more accuracy past a certain point takes more memory/computations/time.

The article then notes that many computations involve Jacobians with sparse matrices meaning some matrix elements can be ignored so we don't have to waste our time on them if handled cleverly.

Subsequent sections cover methods to identify and label sparsity patterns. The article explains how applying their proposed coloring techniques to large matrices common in machine learning yields significant efficiency gains.

As far as the mathematical heritage, I don't know the family tree, but I suspect it stems from courses blending matrix theory linear algebra and algorithms so you'd want the computer science version of such math. Functional approximation ties to numerical methods though I am uncertain if introductory texts cover Jacobians. Check out Newton's method to grasp its mechanics and understand how that works then explore its Jacobian extension. For the coloring aspect graph theory is where to turn. You can learn its basics with minimal prerequisites by studying the seven bridges problem or the map coloring problem, do the five color version. Many of these concepts can be simplified into small programming projects. They will not rival Matlab but they will solidify your understanding.

The blog post mentions in an aside that "The authors of this blog post are all developers of the ASD ecosystem in Julia." which might be the closest thing to an intellectual school that this kind of work is associated with.

Blog post author here, happy to answer any questions you may have!

The prerequisites for understanding the blog post are an undergrad course in calculus and linear algebra, and some graph theory. I can look up some accessible resources if you're interested :)

>Is this type of analysis a part of a particular mathematical heritage ?

It is a mixture of two very much related areas of mathematics. Analysis, called calculus in the US, and numerics.

The ideas behind automatic differentiation arise from the question of how to compute the derivative of a function on a computer. The "derivative" part is the Analysis part and the "on a computer" part is the numerics.

As it turns out writing down the formal definition of the derivative and approximating it on a computer has many undesirable properties. So alternative approaches, like AD, were developed. But AD is much older than the recent Neural network trend.

The hessian is needed for optimization and this blog post was most likely motivated by improving the method used in the precursor blog post: https://iclr-blogposts.github.io/2024/blog/bench-hvp/

You might also be interested in Spadina for Enzyme. There are no Julia bindings yet but I’d be excited if someone made them! https://c.wsmoses.com/presentations/weuroad23.pdf

It seems to be based off of Al-Folio, MIT licensed

https://github.com/alshedivat/al-folio

That's really impressive! I can't even imagine implimenting sparsity tracing in a language as dynamic and hard to compile as R.

Indeed, CasADi is among the precursors in this area! The key difference with our approach is their use of a domain-specific language, with distinct mathematical functions and array types. This has lots of benefits, but it expects users to rewrite their existing code in the CasADi formalism. What we seek to achieve in Julia is compatibility with native code, without a DSL-imposed refactor. We share this ambition with the broader Julia autodiff ecosystem, which is focused on differentiating the language as a whole. Of course it doesn't always work, but in many cases, it enables a plug-and-play approach to (sparse) autodiff which makes really cool applications possible.