Numeric Computing with Node.js

Survey

Overview

Why JavaScript?
State of JavaScript
State of Ecosystem
A Standard Library
The Future

JavaScript

Language of the Web


import beep, { foo, bar } from 'beep';
import beep from 'beep';
import { foo, bar } from 'beep';
import { foo as fu, bar } from 'beep';
import * as beep from 'beep';
import 'beep';


const beep = require( 'beep' );

MATLAB

R

Python

Mathematica

Julia

Why?

Dynamically compiled
U/Int64
BigInt/BigNumber
Single-threaded
Performance
C/C++/Fortran bindings

Dynamically compiled: so are R, Python, Julia, etc.
Int64: but neither does R (https://www.r-bloggers.com/r-in-a-64-bit-world/; requires 3rd party package); in Python v2, had a "long" type (arbitrary-precision integer, which depending on how implemented can be a bit slower than dedicated machine types), which is now true for all integers in Python v3
No native BigInt/BigNumber support: neither does R (need to use a package), MATLAB requires a toolbox, Python uses arbitrary-precision integers
Single-threaded: so is R
Perf: R is notoriously "slow" (slow being a relative term); JavaScript is faster (cue a couple benchmarks)
C/C++/Fortran bindings: Node.js native add-ons and WebAssembly

Community.

Libraries.

Libraries: lack of comparable libraries (e.g., NumPy for JavaScript does not exist). This is a fair criticism.

Lack of libraries may be a reason to not use JavaScript for a particular application requiring such libraries here and now; however, this does not preclude us from creating those libraries so that future applications are not limited by a lack of available libraries in the first place.

But...what about first mover advantage? Those libs took years to develop and optimize? True. However, people working on this now have "last" mover advantage. The R&D has been done. Bringing to JavaScript is a matter of putting in the time and effort to read, understand, and implement comparable implementations. Not a piece of cake, but also not a herculean challenge.

Why?

Web APIs
Rendering
Visualization/Computation
Ubiquity
Distribution
Package Management

Applications

Edge Computing
Cross-platform
Compute Intensive
Interactive Data Analysis
Integrated ML
AI Powered

Mad science.

State of Math in JavaScript

acos
asin
atan
atan2
cos
sin
tan
acosh
asinh
atanh
cosh
sinh
tanh

abs
exp
log (ln)
pow
sqrt
sign
cbrt
expm1
log10
log1p
log2

ceil
floor
round
fround
trunc

max
min
random
hypot
clz32
imul

In ES5, the standard math library consisted of 18 functions and 8 constants. These functions can be categorized as trigonometric, other special functions, including rounding, and miscellaneous, including a PRNG.

ES2015/ES6 added 17 more functions to the standard math library. Again, these functions are broken down into trigonometric, other special functions, including rounding, and miscellaneous.

The addition of these 17 functions means the JavaScript standard math library has 35 functions.

In short, the JavaScript standard math library is quite small, especially when compared to other languages and dedicated numeric computing environments.

In comparison, the Golang standard math library has 54 functions (JS has 35), 8+ PRNGs, as well as support for 64-bit and 128-bit complex numbers. Notably, Golang has equivalents for most C/C++ standard math library functions.

Besides being small, the JavaScript standard math library has other problems.

No standard algorithms.
No minimum precision.
Portability.
No common codebase.
Slow pace of innovation.
Bugs.

ECMA-262 does not specify particular math algorithms (only recommends); hence implementors are free to choose algos according to speed/precision trade-offs.
ECMA-262 does not require a minimum precision; hence, no guarantee that a given JavaScript environment has a precise implementation.
Portability is non-existent for numeric computing applications due to potential cross-browser variability and potential variability from one browser version to the next.
No common codebase, so resolving issues takes considerable time and effort, especially when different vendors use varying implementations in varying languages with varying organization and structure.
Specification-level changes require cross-browser vendor consensus, causing the pace of innovation at the standards level to be slow (e.g., U/Int64 support has been on the table, off the table for more than a decade, and is most recently on the table as part of a BigInt proposal).
Bugs are common (cue bug or two; e.g., `pow`).

Math.pow


var x = Math.pow( 10, 308 );
// returns:  1.0000000000000006e+308
// expected: 1.0e+308

Math.exp


var y = Math.exp( 100.0 );
// returns:  2.6881171418161485e+43
// expected: 2.6881171418161356e+43

What's being done?

Not much.

The fragmentation problem.
The portability problem.
The versioning problem.
The flexibility problem.
The backward compatibility problem.
The globals problem.
The testing problem.
The trust problem.

Updating the specification does not solve the "fragmentation" problem. Notably, even if you agree on a particular algorithm for computing e^x, asking 5 or more different vendors to implement said spec, each in their own way in accordance with their own code base and conventions increases the likelihood that at least one of them will make a mistake, thus leading to the "portability" problem.
The "portability" problem is exacerbated by the lack of implementation versioning. Meaning, I cannot independently specify what version of a particular vendor implementation I want in a given runtime, which may be important if I want to guarantee exact reproducibility of my results. In an "evergreen" world, each browser restart means I might have a different underlying implementation.
On the flip side, mandating a particular algorithm at the specification level coupled with the "versioning" problem would lead to the "flexibility" problem and a corollary "backward compatibility" problem. Currently, because vendors are not required to either use a particular algorithm or meet precision requirements, they have been free to choose algorithms which, for example, favor speed over accuracy, and because no guarantees have been made in the specification, users cannot expect or rely on consistent implementations, thus allowing vendors to avoid backward compatibility requirements when changing underlying implementations. In short, "we can change our algo and even intentionally sacrifice precision for speed because the spec allows us to." There are reasonable arguments in favor of flexibility, but the domains to which they apply are NOT numeric computing!
Other problems include the "globals" problem (i.e., you cannot trust that the host environment has not been hijacked by some other library), the "testing" problem (i.e., browser vendors have historically failed to rigorously test their implementations), and the "trust" problem, which underscores all the other problems.

State of the Ecosystem

False assumptions.
Low hanging fruit.
Poor implementations.
Insufficient scope.
Lack of ambition.

First, most libraries assume a good standard math library. As we already discussed, this is false. Any library which makes this assumption is at an immediate inherent disadvantage.
Next, much of what you see in JavaScript and on npm are the same types of libraries all addressing the same low hanging fruit (e.g., calculating the mean, variance, and standard deviation of an array), with minor differences and stylistic variations. And while the idea is fine, most people writing these libraries are either not numerically trained or simply have not done their homework as to how to write robust algorithms, which means the implementations of even the most basic functions are poor.
One of my basic litmus tests for any math library is how a library computes the variance. The classic definition involving the sum of squared differences is ill-suited for numeric computation due to the risk of overflow and catastrophic cancellation. Unfortunately, a majority of libraries fail this test.
Next, a few libraries have pushed the boundaries of what is possible. For instance, Andrew Karpathy's ConvNet.js, which does "deep learning" in a browser, or Weblas, which tries to implement BLAS algorithms via WebGL to run on graphic cards. However, these libraries are too often more proof-of-concepts than general frameworks which provide a solid foundation on top of which we can build more advanced numeric computing libraries.
Next, there is the work of Mikola Lysenko, who showed how the same multidimensional data structures used in NumPy, Julia, R, and MATLAB, and required for interfacing with BLAS libraries can be implemented in JavaScript (`ndarray`). However, despite this trailblazing work, the community has yet to effectively harness the concept of an ndarray within a general purpose computing framework.

A lot of noise.

1000+ Packages

A standard library.

So what's needed?

Your help.

Thank you!

https://github.com/stdlib-js/stdlib
https://www.patreon.com/athan

Numeric Computing with Node.js

Survey

Overview

JavaScript

Language of the Web

Why?

Community.

Libraries.

Why?

Applications

Mad science.

State of Math in JavaScript

Math.pow

Math.exp

What's being done?

Not much.

State of the Ecosystem

A lot of noise.

1000+ Packages

A standard library.

So what's needed?

Your help.

Thank you!

Appendix

The End