Is your approach specific to the case where the matrix fits inside cache, but the memory footprint of the basis causes performance issues? Most of the communication-avoiding Krylov works I've seen, e.g [0,1] seem to assume that if the matrix fits, so will its basis, and so end up doing some partitioning row-wise for the 'large matrix' case; I'm curious what your application is.

[0] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-..., e.g. page 25. [1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-...

https://dns.squish.net/traverses/de494a9fe3310415f30369a9cb1...

Or more precisely, lukefreed.xyz has NS records pointing to ns[1234].afraid.org, and the DNS servers for _afraid.org_ are subtly misconfigured (one of the six nameservers for afraid.org is evergreen.v6.afraid.org, and since you are trying to look up something in afraid.org but you already trying to resolve afraid.org, you'll need some extra “glue records” as part of the NS response, which is missing for that specific server).

Or is this mostly a problem when you actually want to calculate the eigenvectors themselves, and not just matrix functions?

I hope you get your pay day, your blog is great!

What are you using this for and why are you working on it?

I admit I'm not personally convinced of the value of Rust in numerics, but that's just me, I guess...

May I ask what you've used to confirm the cache hit/miss rate? Thanks!