Hacker News Reader

Comment by hota_mazi | Hacker News Reader

> how do I find eigenvalues and eigenvectors? The function is called ev!

Why not call that function eigen-vectors instead of ev?

Some library authors need to be smacked on the head with a programming book and learn how to design sensible API's.

Seriously, Clojure is typically easy on the eyes but this is just garbage:

    (require '[uncomplicate.neanderthal
       [core :refer [col entry nrm2 mv scal axpy copy mm dia]]

axpy? mm? dia? nrm2?

View on HN

You are walking into a classic argument about concise notation for experts versus self-explanatory names for generalist programmers. See https://news.ycombinator.com/item?id=14239228 for a previous iteration of this argument on this site.

Suffice it to say that anyone with sufficient mathematical expertise to actually make sense of this stuff, who is going to do anything interesting will want to use concise names. And yes, this will be the first thing that a programmer who doesn't know it will complain about, but it is far from the largest problem that you have to face in using this stuff. And if you work through the actually important barriers to doing useful stuff with this knowledge, you'll probably appreciate concise notation.

It's still an interesting idea to try to expose an unknown domain in terms of a well thought out API which takes care of some of those dirty details. An ORM would be an example. Should linear algebra API be the raw numerical algorithms (Fortran like) or something dressed up which throw exceptions on failed convergence?

(This is probably orthogonal to your comment btw )

Any abstraction layer built on top of linear algebra intended for non-mathematicians should be given mnemonic names that are domain specific for what that abstraction layer is aimed at.

Any abstraction layer built with the purpose of making it easy to do linear algebra in software should use names that are domain specific to linear algebra. Which will be the short concise names that make sense to those with mathematical expertise, no matter what generalist programmers think of said names.

I think most programmers probably either need control of the nitty-gritty of the numerical algorithms or would be better-served by a library explicitly modeling their domain (with library authors minding the p's and q's of the numerical algorithm).

Concise notation really lets you see the AST of your code.

I'm more than willing to memorize some inscrutable names in exchange for this capability.

These are not names designed for people who understand linear algebra from an undergraduate mathematics course, they’re just names taken from BLAS, which were chosen based on the conventions of Fortran code.

There’s no particularly good reason to shorten `norm` to `nrm` except to be cryptic.

Knowing that `mv` means “function that takes two arguments and multiplies the matrix in the first argument by the vector in the second argument” and that `axpb` means “takes three arguments, and multiplies a scalar by a vector and then adds it to another vector” and that `scal` means “takes two arguments and multiplies the scalar first argument by every element of the vector or matrix in the second argument” requires familiarity with BLAS. In general the names are fairly un-systematic. Once you’ve learned them reading code is reasonably straight-forward (albeit much less clear than code written using more explicit syntax like you’d find in Matlab or similar), but writing code is going to require either frequent trips to the docs or some time spent on memorization.

I want to point out that axpy is an abbreviation of a * x + y, pronounced "a x plus y", hence axpy. So I disagree with "un-systematic".

“Systematic” would be e.g. `ab`, `ax`, `axpy`, `kx`, instead of `mm`, `mv`, `axpy`, `scal`. (Or whatever other preferred system, hopefully something carefully thought through rather than slapped together.)

The names are obviously meaningful, they’re just fairly ad-hoc and not guessable a priori.

I may offer you an angle here:

xpy uses x and y because x and y could be vectors, but can also be matrices

mm can not be used for vectors, only for matrices.

Of course, the main reason is that these are names used for the last 40+ years in the standard for this type of software, BLAS.

I would say mm and mv name the types of the arguments, like a kind of Hungarian notation, which makes them okay. I think `ab`, `ax`, `axpy` make the problem worse: in the first two a and b are matrices and in the last a is a scalar. As for `kx`, anything named `k` is usually supposed to be an integer like everywhere else in mathematics (why not `ax` then?). As for scal-scale and nrm-norm, I have no idea why they did that, it seems wrong to me too.

Furthermore, it's a specialist expert subdomain—the names are already so standard that everybody who needs them already knows them or looks them up in a second. So I don't see "not guessable" as a valid criticism.

Because when you string a couple of those please-compute-eigen-vectors-and-also-eigen-values in nested calls, you easily end up with a multi-page text in no time.

Besides, the standard way to call eigenvectors/eigenvalues function is ev in LAPACK - sgeev/dgeev.

Renaming "ev" to "eigen" will result in multi pages of text?

And even so, we know today it's preferable to have longer but easier to read code than this kind of garbage.

> sgeev/dgeev.

That's just as bad.

But eigen-what? There are multiple subtle variations of these functions.

On the other hand, you are free to choose libraries that you use. There is surely no shortage of libraries than invent those "proper" names.

You might have a different opinion once you have written a few tens of thousands lines of numerical code. There is a reason why mathematical notation is so terse - much terser than the “garbage” you bemoan, in fact.

Also, regarding your specific example, `eigen` would be ambiguous. Do you mean eigenvalues? Eigenvectors? Eigenfunctions? Eigenspaces?

Well, the author of Mathematica has chosen elaborate names for functions. Everything is explicit. Super long camel-cased names.

It would be interesting to have a language with first-class(ish) support for "tagged" aliases, where an IDE could then expand to short/long versions as configured. To some extent you could already do it in a lot of languages which support annotations/decorations, but it might be nice to have it more built into the language for "standardization" if nothing else.

Those are standard function names in most lin-alg related packages.

I'm fond of "eig" which in Matlab is the function to return eigenvectors and eigenvalues. My experience is that it's easier to recognize and remember abbreviations rather than acronyms.

Why do we have shell commands called `cp` and `mv` instead of just `copy` and `move`?

Same stupid reason. We've learned a lot since those times.

> axpy? mm? dia? nrm2?

Those are the standard BLAS names for those things.

BLAS and LAPACK have an excuse, they come old school Fortran (FORTRAN 77) that originally had a max on function name size.

But people have a reason to know those abbreviations, just like Unix programmers have a reason to know names like "stat" and "fctnl" and "ioctl".

Reply on news.ycombinator.com