
Show HN: libRmath.js – A port of R's Nmath numeric library to JavaScript - Jacobot
https://github.com/jacobbogers/libRmath.js
======
sheetjs
JS can be a serious language in the data science and scientific computation
fields, but one of the biggest ecosystem weaknesses is the lack of numeric
libraries. This library is very promising!

~~~
johndough
Unfortunately it is impossible to implement efficient numeric libraries in
JavaScript due to the lack of SIMD and GPGPU.

~~~
dagw
I assume you're talking about in the web browser/pure js? Because otherwise
you can just bind to the native CUDA etc. libraries like most other languages
do.

And even on the browser side SIMD is being implemented in WebAssembly and
(limited) GPGPU will be possible via WebGL 2.0 compute shaders. So as such I
don't see any reason why JavaScript couldn't at the very least match
python/numpy in performance if someone put their mind to it.

~~~
johndough
About 5 years ago, SIMD.js has been announced, was implemented and then
scrapped in favor of SIMD in WebAssembly, which does not exist until today. It
has been announced, but I would not hold my breath for it. Presumably we'll
only get 128-bit wide SIMD anyway, so another 2x to 4x waste of computing
power there.

Additionally, 4 years ago, WebCL was announced and implemented in some
browsers, but then it was scrapped in favor of compute shaders in WebGL 2.0.
When WebGL 2.0 finally arrived, it did not have compute shaders. Instead, they
have been delayed to be implemented as an extension at some indefinite point
in the future.

Sorry if this sounds a bit grumpy, but I have been disappointed too often to
be enthusiastic about this.

There are also issues like floating point rounding modes in JS and floating
point precision in WebGL that have to be addressed. Should not be too hard,
but who knows.

------
Jacobot
I Want to put this here as a first level comment, some people (well actually
only one) are making up stuff that JavaScript "fudges" floating point numbers.

Some ppl are going to make up drame to "sound interesting" but i dont see how
that is FACTUAL.

The README contains over 8900 lines of 200+ well documented standalone code
examples samples comparing JS and R code ,side by side for every function
call.

THE RESULTS ARE EXACTLY THE SAME!!

Name dropping like web

------
RobertRoberts
I am really suspect of this being actually useful for highly technical work.
Why? Because I work with R, and the math that is done has very specific
results that fudging floating point numbers may be a concern. I don't know
enough about Javascript to be certain, but I feel like (from memory) that it
does not maintain numeric accuracy at a certain level.

I am not the R nerd, my friend with the PhD is, I just do the coding around it
and help clean up his brainy coding. (ie, he can code ok, so he creates the
initial R code, and I clean it up so I don't go mad having to work with it)
But he explained that even Excel (which I will bet is more accurate than JS)
will put out inaccurate results because of number fudging at some level.
(again beyond my nerd level to grok)

All of this is too bad, because R syntax is just plain rotten icky stuff. (but
I may be seeing things with some of the examples looking like awful R
syntax... maybe I need sleep)

Edit: Here's a comment on JS number accuracy, basically what I recalled. (this
is a quick search, so take some salt with it). The issue being how JS decided
to "fix" the numbers for me, felt like the magic semi colons, only not as
predictable.

 _" In JavaScript all numbers are IEEE 754 floating point numbers.[1] Due to
the binary nature of their encoding, some decimal numbers cannot be
represented with perfect accuracy. This is analagous to how the fraction 1/3
cannot be accurately represented with a decimal number with a finite number of
digits. Once you hit the limit of your storage you'll need to round the last
digit up or down."_

[0] [http://adripofjavascript.com/blog/drips/avoiding-problems-
wi...](http://adripofjavascript.com/blog/drips/avoiding-problems-with-decimal-
math-in-javascript.html)

[1]
[https://en.wikipedia.org/wiki/IEEE_754](https://en.wikipedia.org/wiki/IEEE_754)

~~~
dbaupp
That problem is normal and expected behaviour for finite precision floating
point: it appears with any scheme for floating point (IEEE-754 or not), as
computers are finite. A significant chunk of the field of numerical analysis
is about controlling the error introduced by floating point.

And, anyway, R uses IEEE-754 for 'numeric' too[0], and will do the same
"fudging":

 _> All R platforms are required to work with values conforming to the IEC
60559 (also known as IEEE 754) standard_

There's fair criticisms that JS may not offer the required control over
rounding modes that R (or the C libs underlying R) provide or the necessary
instructions to minimise error accumulation, but general handwavings about
"fudging" of floating point don't apply: floating point is unavoidably
imprecise, and R and JS even use the same basic format.

[0]:
[https://stat.ethz.ch/R-manual/R-devel/library/base/html/doub...](https://stat.ethz.ch/R-manual/R-devel/library/base/html/double.html)

~~~
RobertRoberts
> _...general handwavings about "fudging" of floating point don't apply..._

Handwaving is all I can do, I am just the tech taking orders.

I just talked with my statistician friend on the phone, here's one issue my
friend just showed me. (integer error, not even floating point)

111,111,111 * 111,111,111 = 12,345,678,987,654,321

(I did this by hand to confirm, he made me the big meany)

Excel, Libre Office, my calculator, Javascript, etc.. all get this number
wrong. But with R there's a library that can add support for numbers this big.
(I guess this is a well known issue)

Edit: _All_ numbers in JS are floating point numbers, there are no integers...
<hmmm>

 _" In JavaScript, all numbers are implemented in double-precision [...] There
is no specific type for integers."_

Edit 2: (for fun) This is from R:

    
    
      > library(gmp)
      > bignum <- as.bigz(111111111)
      > mul.bigz(bignum, bignum)
      Big Integer ('bigz') :
      [1] 12345678987654321
    

[0] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Guid...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Guide/Numbers_and_dates)

~~~
dbaupp
_> Handwaving is all I can do, I am just the tech taking orders._

Even "the tech" can have some understanding of finite precision integers and
floats, and how they behave, given they're building blocks of the trade. It
seems somewhat relevant to knowing what changes are valid to code.
[http://floating-point-gui.de/](http://floating-point-gui.de/) is a great
place to start if you're interested in learning more. :)

 _> Edit: _All_ numbers in JS are floating point numbers, there are no
integers... <hmmm>_

Not having any native integers is unfortunate and annoying, but there are
various tricks to ensure numbers are integers (e.g. floats exactly represent
integers up to 2^53) plus various tricks to convince the JS engines that
things are guaranteed to be integers for optimizations. These are clunky and
ugly hacks, but they're _possible_ and even more possible when using JS as a
compilation target from a different language (e.g. asm.js in the extreme).

 _> I guess this is a well known issue_

Indeed, it very much is. As you demonstrate, even R doesn't allow doing your
example calculation natively, you need to import a library... something that
can be done just fine in JS too: for arbitrary size integers
[https://github.com/Yaffle/BigInteger](https://github.com/Yaffle/BigInteger)
and for arbitrary precision floats
[https://github.com/charto/bigfloat](https://github.com/charto/bigfloat)
(among many examples). It's true that these won't approach the performance of
GMP due to lack of access to the specialized instructions it uses, but they
offer the same basic functionality.

That said, I agree with the general sentiment that JS is suboptimal for
scientific computing, but mostly because of performance (although R's
performance falls off _very_ quickly when using anything other than vector
operations) rather than inaccurate concerns about precision.

~~~
RobertRoberts
> _Even "the tech" can have some understanding of finite precision integers
> and floats, and how they behave, given they're building blocks of the
> trade._

I do have "some understanding". But not enough to processing millions of
records and notice that one or two numbers of output, out of hundreds, aren't
correct. That's the PhD's job.

~~~
dbaupp
Concepts like finite integer sizes (aka integer overflow) and finite floating
point precision (1/3+1/3+1/3 != 1) aren't PhD-level concerns. :)

------
williamstein
I sometimes wish I had launched a similar porting effort with SageMath...

------
nickreese
Perfect timing. Author if you’re reading this thanks for sharing/porting this,
was just on github looking for a solution yesterday.

~~~
Jacobot
Thanks, Note, JS is breaking benchmarks if compared to Python!

------
pamparosendo
Great work. Thanks!

