Jmat.js: A new mathematics library in JavaScript | Hacker News Reader

Jmat.js: A new mathematics library in JavaScript

lodev.org

84 pointsjmatjs13 comments

Looks interesting!

However, when posting a new package it is most useful to discuss it in comparison to established packages. Specifically, what are the pros/cons of this package compared to numericjs [1] and jstat [2]?

Also, in general, I think it is a mistake to mix plotting and numerics in a single package. These are two quite different things and are probably better served by more focused packages.

[1] http://www.numericjs.com/ [2] https://github.com/jstat/jstat

Thanks for the feedback.

There is some overlap between those libraries. However, it does one thing that none of the other JS libraries (from here: http://jster.net/category/math-libraries) really focus on: to support the full complex domain for all the functions.

About numerics vs plotting: They are in different js files, jsmat.js and jsmat_plot.js. The plotting file depends on the numerics one though, as it needs to use its Complex type. The main focus of the package is the numerics, the plotting is a demo, and especially, debugging device.

Nice library! For some strange reason, Excel, Mathematica, and bessel on npm (http://npm.im/bessel) disagree with Jmat.js for the bessel family:

    SetPrecision[BesselY[10,10],20]   -0.35981415218340272205
    require('bessel').bessely(10,10)  -0.35981415215916784
    =BESSELY(10,10)                   -0.35981415215916800
    Jmat.bessely(10,10)               -0.3598156646154304

The Bessel function(s) are pretty difficult to calculate and generally have to be calculated numerically via any of several methods. Looking at the numbers you posted, I'd say that Jmat is probably using a different algorithm and/or precision level than the others. My hunch would be that it's using a series expansion, while the other software is using one of the more clever algorithms.

PS: In Mathematica, you should probably use "N[..., 20]" instead of "SetPrecision". It not quite the same and using SetPrecision can cause odd effects if you're not careful, like accidentally triggering numerical evaluation too early.

It looks like Jmat is using the series expansion (about zero) for Re(z)^2 < (Re(n)+1)/10, with z the argument and n the order. They switch to the asymptotic form for larger arguments, but they're only using the first term.

To improve accuracy, they could truncate the large order expansion when the terms start growing or drop below precision. See the wonderful DLMF S10.17 (http://dlmf.nist.gov/10.17) for the higher order terms.

Note that this expansion will not perform well for large order, and they should switch to one of the series in order instead. Olver's uniform expansion is lovely, but a bit tedious to implement.

Ok, improving the Bessel functions is now the first priority thing to fix :)

I think JSmat would be a more appropriate name. Java libraries usually start with J so Jmat leads to confusion.

Could we see some demos of basic usage for solving linear algebra homework, i.e., can I haz a CAS in the JavaScript console of my browser?

Also I'd like to see some 2D plotting examples of basic functions of the form f:R->R. I'm looking for a simple .js lib for plotting...

Seems silly to write what already exists in C. Just compile with Emscripten.

Sure, because everybody wants a 2-10MB additional download of mangled transpiled Javascript code for their app.

You do realize that Emscripten compiled code will be way smaller and faster than the equivalent JS code. Because C has static typing.

You do realize that static typing has nothing to do with code size (where did you get that bizarro idea from?).

Emscripten transpiled code is a bloated of redundancy in order to cover C constructs in Javascript code, for things that can be done shorter in idiomatic javascript. But you don't have to take my word for it. Check emscripten transpiled stuff that's out there and their sizes (even compared to the equivalent executable binaries for the same code).

Faster it might be (if it uses asm.js style tricks), but have you profiled to ensure that speed is lacking on that particular codebase we're talking about? Or that you can't just have a minimal asm.js/emscripten style base core and do the higher level stuff in pure high level js?

You make the claim that pure JS would be smaller than Emscripten compiled JS because of having to support C constructs in an awkward manner. This might be somewhat true in regard to pointers but not enough to make a difference. Please show some example codes

Reply on news.ycombinator.com