decomposition and factorization terminology

[Sacha0]

Singular value decomposition factorization (svdfact) is a slightly unfortunate name; minor a thing as it is, the redundancy chafes. Perhaps svdecomp, svfact, or something similar would be better? Best!

[antoine-levitt]

The usual acronyms are LU, QR, SVD. Unfortunate perhaps but well established, so it would be better to have consistency across these factorization rather than consistency of the name itself. Reading svdecomp for instance makes me wonder what an ecomp is.

[ViralBShah]

It never occurred to me, but now that you mention it, it does sound weird. However, I don't ever expand the SVD in my mind when I think about it, and perhaps it is ok to let it be as it is.

[Sacha0]

A broader thought in the same vein: At the moment we mix the terms decomposition and factorization (e.g. Computes the eigenvalue decomposition of A, returning an Eigen factorization object F [...]). Decomposition is the more common and slightly more general term. Perhaps we should use decomposition consistently? Best!

[ViralBShah]

I believe there was a discussion thread on which name to use, and we picked factorizations early on. We should dig up and link the original discussion at the very least.

[Sacha0]

A bit of git spelunking revealed the following history: Miles Lubin introduced the name lufact confined to an UMFPackLU wrapper via JuliaLang/julia@53c2d30. Later, Doug Bates introduced *d names, e.g. lud and qrd, for decompositions broadly via JuliaLang/julia#1281 and JuliaLang/julia#1290. In JuliaLang/julia#1281, Viral pointed out that the *d names were opaque, and suggested extending the UMFPackLU lufact to *fact/ "factorization" generally instead. Shortly thereafter, Tim Holy suggested *dcmp/"decomposition" as an alternative, and Doug Bates expressed remorse for introduction of "factorization" terminology and a preference for *decomp/"decomposition", but said he'd go with either decision. Viral responded saying he would be happy with either name and left the call to Doug, though he liked *fact's brevity. Mike shared a little support for "decomposition" then, and Doug likewise. That's where the conversation appears to leave off. Viral later committed JuliaLang/julia@69e407b, renaming the *d functions to *fact, and here we find ourselves :).

Out of curiosity, I checked the number of google hits for "X decomposition" and "X factorization", and while I had the impression that decomposition was the more widespread term, the degree to which that appears true surprised me; results in millions below:

Update regarding the table below: These hit counts were for unquoted search queries, whereas quoted search queries are probably a better metric. With quoted queries, which term hit counts favor depends on the decomposition, and the results are much less compelling overall. Ref. #519.

X	decomp	fact
lu	15.3	1.07
qr	12.3	0.34
singular value	2.58	0.68
eigen	0.41	0.08
cholesky	0.4	0.2
schur	0.28	0.43

Tangentially, the history suggests that the only reason for the *fact/*d names was to retain MATLAB compatibility in lu, qr, and friends. But with the MATLAB-like functions lu, qr, et al now being deprecated in favor of *fact, deprecating the *fact names to lu, qr, et al becomes possible in 1.x (discussed briefly in JuliaLang/julia#25187). Best!

[ViralBShah]

Thank you for that detailed analysis!

[StefanKarpinski]

Yes, I'm very much in favor of making breaking changes to LinearAlgebra 2.0 in some Julia 1.x release where the names are just lu, schur, chol, etc. but the objects returned are factorization objects. We can retain the ability to write code like L, U = lu(X) but defining iteration of the factorization objects to yield the expected components. Let's spend the intervening time thinking about what the best design for this kind of API would be without any historical baggage.

[Sacha0]

Yes, I'm very much in favor of making breaking changes to LinearAlgebra 2.0 in some Julia 1.x release where the names are just lu, schur, chol, etc. but the objects returned are factorization objects. We can retain the ability to write code like L, U = lu(X) but defining iteration of the factorization objects to yield the expected components.

Agreed! And likewise Andreas it seems. JuliaLang/julia#26997 should at least set us up for those changes during 1.x, and potentially non-breaking then. Best!

[ViralBShah]

I am not sure how these Google hits were computed, but I don't get anything above 150,000-ish on anything, and even so, no more than 13-14 pages of results.

[Sacha0]

I am not sure how these Google hits were computed, but I don't get anything above 150,000-ish on anything, and even so, no more than 13-14 pages of results.

The difference is quoting versus not quoting the search query :).

[ViralBShah]

I think one ought to quote it, which is what I thought you did since you did say "X decomposition" and "X factorization". Even if I do it without quotes for lu, I get the same numbers roughly, about 1.2-1.3M, and not 15.3M vs. 1M. I don't think Google hits are a reliable way to decide this.

[Sacha0]

A slack conversation convinced me that the hit counts for quoted search queries are a better metric, and for such queries which term the hit count favors depends on the particular decomposition; in other words, ignore the table above, as it's probably not the best guide. The remaining question is a minor one of correctness, in that e.g. decomposition is in some cases perhaps more correct for eig than factorization, but whether that's worth bothering about 🤷‍♂️. Best!