Refactor: replace numeric with mathjs

[idiotWu]

Resolves #211.

This PR replaced numeric with mathjs to fix the CSP error as mentioned in #211.
I'm not able to run the test script because files under www/data/src/P_01/ are missing, but the demo pages seem to be working.

As a side effect, the bundle size increased from 2.1M to 3.2M (both minified).

[idiotWu]

I don't think this works since neither the numeric nor the mathjs variable is exported to the worker global scope. (as commented in #163 (comment))

[Skylion007]

Yeah, we need to fix that separately.

[Skylion007]

math.js has a qr decomposition too, right?

[idiotWu]

Right, but the two functions are different: mathjs.qr(A) only decomposes matrix A, while mat.QRDecomposition(A, b) solves the linear system Ax = b

[idiotWu]

The equivalent qrsolve() function can be implemented as:

function qrsolve(A, b) {
  const { Q, R } = mathjs.qr(A);
  const dim1 = A[0].length;
  
  return math.multiply(
    mathjs.inv(R.slice(0, dim1)),
    mathjs.transpose(Q).slice(0, dim1),
    b,
  );
}

However, I don't think it will be faster than the current one.

[idiotWu]

Those implements in mat.mjs seem to be much faster than mathjs in my tests:

Test Code

[Skylion007]

WOW. Just wow. Add a comment so we don't accidentally use them in the future. We should verify the matmul and other functions in math.js are actually faster.

[idiotWu]

mat.mul() is also faster than mathjs.multiply() after 1M runs:

Maybe mathjs is wasting too much time constructing matrix instances 😞

[Skylion007]

Rather disappointing. Are there any other good candidates that may work better than math.js. Surely something has to be faster than numeric, maybe something that even leveraged WASM?

[idiotWu]

In my tests, mat.* >>> numeric >> ml-matrix ~ math.js. Libraries like math.js add extra checks to ensure operations can be performed, which causes a decline in performance. Maybe the best solution is to implement all the required matrix operations ourselves.

[Skylion007]

mat.mul() is also faster than mathjs.multiply() after 1M runs:

Maybe mathjs is wasting too much time constructing matrix instances 😞

Looked into the code and apparently the matrix instances are just a wrapper around associative arrays so that shouldn't slow it down. I did see that it did have serious speed issues though. It's designed to be flexible and extensible, not fast.

[Skylion007]

Yeah, I found that Math.js wraps normal JS arrays. Hence why it's slow. It also doesn't do a lot of optimizations. It seems to be more focused on correctness and extensibility than speed sadly.

Instead of reimplementing all these ourselves, I would like to see if there is a well-supported LinAlg library we can leverage. At the very least, we are using arrays of arrays in JS which are really slow, so anything that doesn't use those should perform faster.

@idiotWu It may be overkill but how does the benchmarking for Eigen.JS look? https://github.com/BertrandBev/eigen-js

[Skylion007]

Here is there official benchmarking: https://bertrandbev.github.io/eigen-js/#/benchmark

[idiotWu]

@Skylion007

At the very least, we are using arrays of arrays in JS which are really slow, so anything that doesn't use those should perform faster.

Well, JS native arrays are actually fast on modern browsers. I thought TypedArray based implement would be faster, but in my tests ml-matrix (the only TypedArray based linalg lib I've found so far) does not seem to be much faster than math.js. What's more, a total refactoring is necessary if we want to use TypedArray.

Eigen.js seems to be as slow as math.js:

[istvan73]

@idiotWu

I just dropped in to say a big THANK YOU!
You've solved the issue which held me back from making my chrome extension. I am super grateful, and going to mention your code as well when the extension will be out.

Istvan

[koll93]

@idiotWu Thanks.
I needed to use webgaizer in google extension with manifest v3 but with new model with landmarks. I used @idiotWu's idea for the latest revision of the webgaizer. https://github.com/koll93/WebGazer/tree/refactor-remove-numeric-landmarks