4 ms·

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 reas

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.

SilasX 7y ago
>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.
- NohatCoder 7y ago
  >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.