Hacker News Reader

Comment by NohatCoder | Hacker News Reader

1. The computation is a handful of simple arithmetic statements, there is almost nothing one can do to optimize those. The library is likely written to handle inversion of any size matrix, that means it adds a bunch of control code to be more general, but also slower for this case.

2. You are wasting effort evaluating libraries. And I wonder what you lose in compile time?

3. You are calling into a black box, and you talk about opacity, a simple comment: /* this inverses the matrix */ will deal with your perceived issue.

4. Other programmers will assume there is a pertinent reason you included yet another dependency. Wonder what it does that 5 lines of code couldn't have done (surprise: nothing!).

View on HN

>The computation is a handful of simple arithmetic statements, there is almost nothing one can do to optimize those.

I'm not sure that's right in this case. For inverting a matrix, it makes a huge difference whether the determinant is exactly zero or just very close, and (IIRC) floating point math may give the wrong answer. A library will have worked through this issue.

The history of various bugs in various very commonly used libraries, with them being extremely obvious after being discovered, strongly suggests this:

If there is some situation that is somewhat likely to come up and needs special code, but it is not immediately obvious (and, going by OP's evident lack of realizing it, that's some proof to say it is not immediately obvious)? It may not be there. And even if it is the common path, it can still be buggy.

Is is less likely that a library with some actual use out there has these bugs vs. handrolling it, but, if you handroll it, you're writing it for _your_ case, specifically with what you have in mind, whereas the library is more general than that. That's usually upside, but there's also downside, in what may be obvious to your usecase may not be obvious to the library.

The central point of the top comment here, that opinions differ and that there isn't actually an obvious answer even if you think there is one, holds true here.

You have already got floating point inaccuracy on the input, even if the library somehow avoid inaccuracy when computing the determinant, it can't tell the reason for a zero or almost-zero arising. What is the library supposed to do? You will have to deal with the issue of either a very big numbers matrix, or no matrix at all, in any case.

This is a great example of the fallacy of believing that a library automatically solves arbitrary issues.

>You have already got floating point inaccuracy on the input,

Not if they come in as integers that have to be coerced at some point.

>What is the library supposed to do?

Compare ad to bc instead of ad - bc to zero, for one.

>This is a great example of the fallacy of believing that a library automatically solves arbitrary issues.

I didn’t say that and don’t believe it. My point only depends on he library having avoided more domain-specific rookie mistakes than I would have caught in five minutes, when it comes to computational linear algebra. Like the sibling commenter, I don’t think libraries are a panacea, and the answer depends on the specifics of the case.

>Not if they come in as integers that have to be coerced at some point.

In which case you can calculate the determinant exactly with your own roll, but a library will likely force you to convert everything to doubles.

>Compare ad to bc instead of ad - bc to zero, for one.

That is the same thing, a compare instruction is basically just a subtract that doesn't write the output, so you get zero/equality in exactly the same cases. Most compilers will probably turn your code into doing just one subtract and then check the flags, no matter which version you write.

Reply on news.ycombinator.com