►
Description
Math in V8 is Broken and How We Can Fix It - Athan Reines, Fourier
The built-in JavaScript Math library is used in virtually every Node.js application, from generating random ids to calculating exponential back-off times to computing basic performance metrics. When using the Math library, most developers simply assume that the underlying implementations are accurate, performant, and correctly implemented. In this presentation, Athan Reines will discuss why this assumption is often false and show the various ways in which the standard library is broken.
The presentation will present the algorithms used, their performance and accuracy, and how they have downstream effects on users of these libraries. The presentation will conclude by highlighting how community solutions are stepping up to fix these problems and identity opportunities for additional improvements.
About Athan Reines
I am a full-stack engineer and data scientist. I have a PhD in Physics, where I used machine learning and time series analytics to probe biological systems at the nanoscale. My current projects focus on numeric computing using Node.js and JavaScript. I have authored 800+ node modules, as well as browser libraries for exploratory data analysis. I have spoken at conferences on the interplay between philosophy and physics, on topics in the biological sciences, and on data visualization within big data pipelines.
A
Definitely
so
just
kind
of
get
started,
just
kind
of
like
set
the
tone
and
give
an
overview.
We
need
to
just
quickly
refresh
on
the
standard
library.
So
the
standard
library
is
often
the
developers
first
introduction
to
math
and
JavaScript.
So
in
es5
you
had
a
collection
of
about
18,
different
functions,
covering
trigonometry
2,
special
functions,
two
other
utilities
and
es6
and
es2015.
A
We
introduced
17
more
functions,
notably
some
other
trigonometric
functions,
plus
some
higher-order
special
functions
and
some
utilities
and
the
grand
total
that
we
have
is
about
35
different
pieces
of
functionality,
plus
eight
constants,
so
just
to
kind
of
do
a
comparison
and
what
you
might
get
in
the
standard
library
in
other
languages.
So
let's
take
a
look
at
golang,
so
in
golang
what
you'd
also
see
as
you
see,
trigonometric
function
and
special
functions.
A
Higher-Order
some
utilities,
as
well
as
low-level
functions
for
manipulating
floating-point
numbers
in
total
golang,
has
54
different
functions
and
it's
standard,
math
library,
plus
8,
different
PR
and
G's,
so
to
create
pseudo-random
numbers
plus
support
for
64-bit,
complex
numbers,
128
bit
complex
numbers
and
big.
Yet
big
float
for
doing
for
supporting
applications
in
cryptography
as
well
as
arbitrary
precision
arithmetic,
so
you
might
be
asking
like.
So
what
why
do
we
care
about?
Go,
laying
having
a
bigger
standard
library
than
the
Java
Script
two
points?
One?
A
Is
that
javascript
for
being
a
20
plus
year
old
language
is
still
quite
deficient
in
terms
of
its
standard
library
in
terms
of
math,
it
stores
quite
a
ways
to
go.
The
second
reason
is
that
these
functions
that
you
get
out
of
a
standard,
math
library,
are
quite
critical,
they're
fundamental
building
blocks
to
doing
any
kind
of
higher
level,
math
like
machine
learning
or
statistics
or
any
kind
of
numeric
computing,
and
it's
really
critical
that
standard
math
functions
are
accurate
and
they're
performant,
because,
if
they're
not
accurate,
those
errors
propagate
to
downstream
consumers.
A
So
if
you
have
a
small
error
and
one
of
your
functions,
let's
say
calculating
the
the
power
of
the
exponential
you'll
do
some
machine
learning.
Algorithms,
you
know
find
out
that
you,
your
results,
significantly
deviate
from
your
expectations,
and
this
can
all
be
traced
back
to
these
these
low
level
primitive
standard
math
functions.
So
it's
really
critical
that
we
get
these
things
right
because
errors
matter.
A
So
speaking
of
errors,
let's
talk
about
some
bugs
that
we
find
in
the
eighth
and
it
kind
of
like
set
the
stage
in
terms
of
v8
and
node.
Just
as
a
refresher
as
a
reminder,
every
version
of
node
is
associated
with
a
particular
version
of
v8.
The
versions
can
fluctuate.
A
little
bit
depend
on
what
version
of
node
you
have,
but
by
and
large
there's
a
major
version
of
v8
associated
with
node
and
why
this
is
important
is
because
take,
for
example,
node
v4,
which
has
an
end
of
life
and
2018.
Well.
A
By
that
point,
it's
associated
version
of
v8
will
be
nearly
two
years
old.
So
during
the
interim,
there
have
been
any
bug,
fixes
or
a
tower
fixes
in
terms
of
accuracy
and
precision.
Those
older
LTS
versions
of
node
will
not
benefit
from
those
those
those
those
fixes
right.
So
everything
and
the
most
modern
version
of
v8
is
up-to-date
and
good.
There's
still
older
versions
of
v8
that'll
be
out
there
and
that's.
A
The
thing
is
that
versions
of
v8
have
a
relatively
long
life
span
in
the
node
community,
and
you
need
to
be
aware
of
this,
and
what
this
means
is
that
old,
bugs
in
v8
are
still
bugs,
because
if
people
will
encounter
them
on
their
everyday
applications,
so
in
terms
of
particulars,
if
we
go
back
all
the
way
to
node,
0.10,
math,
sine
and
cosine
are
not
accurate.
You
can
get
back
values
of
the
wrong
sign.
Also,
the
wrong
magnitude
going
forward.
A
Nan's,
most
people
think
that
there's
only
like
one
nan
in
JavaScript
and
by
the
specification.
Yes,
however,
and
the
underlying
implementations,
you
can
get
distinguishable
Mane's,
and
you
can
actually
see
this
if
you
put
Nan's
into
to
raise-
and
you
actually
look
at
the
underlying
bit
sequences-
which
we
can
do
here
by
overlaying
and
32
array,
and
we
see
that
actually,
the
underlying
bit
sequences
are
different,
and
this
because
Nan's
are
not
canonicalized
on
right
in
terms
of
performance,
but
they
are
on
read.
A
So
if
you're
doing
some
kind
of
low-level
float
manipulation,
you
need
to
be
aware
that
the
underlying
bits
of
Nan's
and
JavaScript
may
not
be
what
you
think
they
are
right,
and
this
is
not
necessarily
a
bug.
Having
distinct
Nan's
is
actually
a
good
thing,
at
least
in
my
opinion,
because
you,
it
gets
JavaScript
a
little
bit
closer
to
the
I
Triple
E
754
floating
point
spec.
A
I
know
because
I
end
up
having
to
fix
bugs
related
to
this,
and
maybe
you're
thinking,
okay.
Well,
maybe
some
of
the
older
things
are
a
little
bit
off.
But
what
about
less?
Some
of
the
newer
stuff,
like
es2015
es6
functions
like
hyperbolic
arctangent,
unfortunately,
from
0.12
up
to
zero,
to
version
six
they're
inaccurate,
as
well
as
hyperbolic
arc,
cosine
and
accurate
and
then
finally
hyperbolic
arc
sine,
is
also
inaccurate.
A
And
if
you
look
at
at
the
example
it
it's
not
particularly
accurate
for
small
valleys
and
large
values-
and
the
reason
is,
is
if
we
look
at
the
algorithm
that
is
used
for
math
for
hyperbolic
arc
sine.
We
see
that
for
small
inputs
we
end
up
doing.
You
multiply
a
small
input
by
itself.
Well,
that
gives
you
an
even
smaller
input.
One
plus
something
that's
negligible
is
just
one,
so
you
start
to
underflow
and
if
you
have
a
large
input,
well,
a
large
value
like
10
to
the
200
times
itself
overflows
to
infinity.
A
So
it's
not
going
to
handle
it
basically
treats
all
values
is
the
same
when
a
more
accurate
algorithm
would
actually
treat
values
differently
based
on
magnitude.
So
this
is
an
implementation
out
of
FD
Lib
M,
which
is
part
of
like
Sun
OS,
the
live-in
family
of
math
functions,
and
we
notice
that
for
small
values
we
probably
one
approximation
for
larger
values
to
apply
another
and
then
so
on
and
so
forth,
and
this
allows
us
to
increase
our
precision
in
our
accuracy.
A
Math
exponential
is
also
inaccurate,
in
this
case,
it's
off
by
26
ULP
units.
In
the
last
place-
and
this
becomes
even
more
apparent
when
you
actually
look
at
a
plot-
comparing
math
expe
compared
to
our
reference
implementation-
and
we
see
that
in
0.10
we're
not
too
far
off,
but
once
you
get
there's
a
change
in
v8
between
zero
point,
ten
and
0.12
such
that
the
implementation
is
actually
quite
far
off
from
the
reference
implementation.
A
So
we
see
even
0.12
all
the
way
up
through
version
six
once
you
get
to
v7,
things
are
remedied
right,
but
this
is
a.
This
is
a
big
problem
right,
because
calculating
e
to
the
X
is
fundamental
on
many
different
applications.
So
if
you're
trying
to
have
high
precision
results
in
your
numeric
computing
library,
well
you're
going
to
contend
with
this.
A
Next,
we
have
math.random,
so
an
older
versions
like
pre
version
5
and
a
node
v8
used
this
particular
algorithm
for
its
PR
and
G
pseudo-random
number
generator,
and
it
is
the
nwc
1616
multiplied
with
carry,
and
you
combine
two
16-bit
parts
to
create
a
32-bit
integer.
There's
a
number
of
issues
that
are
wrong
with
this
pair
in
g1
is
that
as
a
relatively
small
period,
it
basically
fails
most
like
statistical
tests
for
evaluating
PRN,
G's
and
then
three,
it's
subject
to
poor
initial
seed
states
that
even
shorten
the
life
of
the
PRG
even
more.
A
So
it's
just
been
kind
of
like
not
a
good
thing.
In
fact,
the
author
original
author
of
this
PRNG
way
back
in
the
day
like
a
couple
weeks
later,
came
out
with
a
new
addition
that
use
an
a
an
X
or
spice.
Let's
say
it's
not
a
good
one,
and
this
comes
back
to
bite
people
when
they
actually
try
to
use
it
in
production.
A
So
if
anyone
has
pulled
along
with
the
bed
Abul
story-
which
is
quite
public
your
so
ago,
basically
what
they
were
trying
to
do
is
they're
trying
to
create
unique
IDs
that
we're
gonna
propagate
throughout
their
system
and
how
they
were
going
to
do
that.
They
had
like
64
characters
and
they
said
alright
we're
going
to
create
a
unique
ID.
That's
22
characters
in
length
if
we
have
a
good
PR
ng
that
should
give
us
about
2
to
the
132
different,
unique
IDs.
All
right
possibility
of
collision
is
pretty
pretty
pretty
small.
A
However,
the
PRNG
that
you
saw
before
the
higher
order
bits
are
basically
controlled
by
only
16
bits
which
effectively
reduces
the
cycle
length.
So
what
actually
ends
up
happening
is
that
you
only
get
2
to
the
30
unique
values,
which
means
that
your
probability
of
collision
is
much
much
greater
right
and
this
is
actually
what
they
found
out
in
production
because
of
a
poor
random
number
generator.
They
have
a
whole
bunch
of
duplicate,
IDs
flooding
through
their
system.
That's
not
a
good
thing
and
just
kind
of
bring
home.
A
So
that's
the
8
and
math
right
now
right
is
that
across
the
different
implementations,
you
have
very
inconsistent
results.
You
have
a
lack
of
precision
and
this
isn't
to
say
that
the
v8
team
hasn't
worked
to
fix
this
right
and
the
most
recent
version
of
the
eight
like
they've
been
working
hard
to
standardize
all
their
mathematicians
etc,
and
this
isn't
v8
specific
right.
This
happens
in
spider.
Monkey
I
haven't
really
evaluated
in
chakra,
I'm
sure
they've
done
amazing
stuff,
but
there
are
bugs
elsewhere.
A
Right
and
part
of
it
is
it's
not
just
like
there
are
bugs,
but
another
reason
why
math
and
the
v8
is
broken
is
because
it's
broken
really
at
the
standards
and
the
implementation
level
right
at
just
JavaScript
as
a
language
not
took
a
brain
on
JavaScript
parade,
but
there's
a
lot
of
work
for
that.
We
need
to
do
and
there
are
basically
ten
reasons
why,
at
the
specification
level,
a
little
bit
broken
first,
is
that
under
specified
in
the?
If
you
read
Ahmed
262,
you
will
see
that
they
don't
mandate
a
precision.
A
There's
no
single
code
base
right:
it's
not
like
an
R
or
Julia
or
Python,
whether
it's
like
one
source
of
truth
because
of
all
the
different
browser,
vendors
and
the
different
implementers.
You
have
many
sources
of
truth
and
that's
hard.
If
you
want
to
push
the
agenda
forward
of
math
and
JavaScript,
though
the
reason
is
versioning
right,
I
could
basically
reboot
my
computer
now
and
restart
chrome
and
I
can't
guarantee
that
the
version
of
math
sign
is
the
same.
One
I
started
with
right.
A
This
notion
of
evergreen
browsers
is
good,
but
it
also
comes
with
some
downsides,
notably
I
have
no
choice
like
I.
Don't
have
any
decisions,
a
black
box
in
terms
of
what
implementation
I
am
given
win
and
that's
an
issue,
because
that
makes
it
hard
to
do.
Reproducible
numeric
computing
and
it
also
affects
portability.
The
next
thing
is
required,
shims.
A
Well,
if
you
need
to
smooth
out
all
these
inconsistencies
and
browser
behavior
and
also
and
node-
and
you
always
having
to
push
this
down
and
use
these
things,
it
kind
of
begs
the
question
why
you
need
a
negative
implementation
to
begin
with,
because
you're
already
having
to
use
third-party
code,
another
issue
is
Global's.
The
fact
of
the
matter
is
is
JavaScript
traditionally
has
been
kind
of
a
hostile
environment.
People
are
always
think
they
have
a
better
implementation,
their
overriding
Global's.
You
really
have
no
guarantee
that
what
you're
using
is
the
right
thing.
A
Another
one
is
testing
is
that
the
spec
doesn't
mandate
any
particular
testing
right
and
if
you
look
traditionally
at
mathematicians
in
JavaScript
by
the
different
implementers
and
vendors
testing
hasn't
has
been
a
bit
wanting,
yeah
and
because
they're
not
really
comparing
against
like
standard
implementations
like
you
should.
If
you
really
want
to
be
thorough,
you
need
to
be
testing
against,
like
let's
say,
boost
or
set
fees
or
FD,
Lib
em
or
something
else.
A
You
really
need
to
be
rigorous
about
your
testing
or
else
you're
gonna
have
bugs
and
that's
been
kind
of
the
history
of
math
and
JavaScript.
Next
is
that
there
are
no
golden
algorithms.
People
think
that
we
can
solve
the
math
problem
just
by
finding
that
one
unique
algorithm
there
is
no
unique
golden
algorithm
right.
People
will
commonly
say
that
okay,
we
need
to
use
it.
A
We
need
to
use
PCG,
which
is
a
particular
type
of
p
rng
random
number
generator
for
JavaScript,
but
the
fact
of
the
matter
is
one
random
number
generators
are
going
to
cut
it.
When
you
want
to
do
serious
computing,
you
need
to
have
multiple
different
generators
to
make
sure
that
what
you're
doing
is
that
an
artifact
of
the
generator
itself?
So
it's
not
like
we
fix
it
by
just
fixing
the
spec
there's
a
much
bigger
issue,
that's
fundamental
at
the
language
level.
A
Next
is
this
time
scale
in
order
to
go
from
specification
implementation
it
takes
years
right.
I
it's
hard
to
say
whether
it's
worth
it,
you
can
move
a
lot
faster
at
the
community
and
user
land
level.
Then
you
can't
at
the
specification
level-
and
that's
has
been
traditionally
the
case.
Mozilla
knew
about
they're
PRNG,
the
random
number
generator
being
weak
back
in
2006.
A
It
wasn't
an
fixed
until
2016
same
thing
with
v8
and
they're
random
number
generator.
It
took
a
long
time
to
get
it
fixed
and
it
takes
a
long
time
to
get
through
things
through
at
the
specification
level,
and
that's
also
why
it's
a
bit
trying
and
a
bit
wanting
to
do.
Math
in
JavaScript,
and
lastly,
is
this
kind
of
underscoring.
A
Everything
is
this
trust
there's
fundamental
trust
issue
here
that
I
can't
rely
upon
various
implementations,
native
implementations
and
the
browser
being
right
or
performant
or
accurate
or
anything,
and
so,
if
that's
the
case,
I'm
just
not
going
to
use
anything.
So
that's
kind
of
dire
might
be
a
bit
depressed
at
this
point,
so
maybe
you
can
think
oh
yeah
I'll
use
some
community
solutions.
That's
right!
Maybe
what
up?
Maybe
the
answer
here
is
that
I'll
use,
polyfills
and
pony
fills
and
shims
and
shams
and
we'll
be
good.
What
a
patch
everything
it's
great.
A
Let's
look
at
one.
This
is
a
polyfill
for
hyperbolic
arcsine.
If
this
code
looks
familiar,
it
should
because
it's
the
exact
same
implantation
that
we
saw
before
the
reality
is
that
many
of
the
polyfills
and
pony
fills
that
you
see
on
NPM
are
just
not
very
good,
I'm.
Sorry
to
say
this,
one
in
fact
comes
from
a
rather
highly
regarded
and
highly
prolific
package
author,
giving
it
an
air
of
credibility
when
it
deserves
no
such
thing
right.
A
Many
things
that
are
implemented
in
npm
are
implemented.
Shouldn't
be
doing
it
right.
So
you
need
to
be
very
aware
of
this.
At
this
point
you
might
be
going
ok.
Well,
maybe
what
I'll
use
is
dedicated,
math
libraries
to
fix
my
problems
right.
Surely
people
that
are
doing
math
well
thought
about
this
and
figure
out
a
solution.
So
let's
look
at
that.
Here
is
an
implementation
that
I
found
that
I
picked
right,
like
yesterday
from
a
very
popular
and
well-regarded
math
library
that
has
like
four
thousand
stars.
A
150
different
Watchers
and
50
different
contributors,
and
this
is
what
you
get,
and
this
is
what
the
lesson
here
should
be,
that
social
indicators
are
really
poor,
metrics
for
evaluating
core
quality.
The
only
way
you're
gonna
know
about
code
quality,
especially
when
it
comes
to
numeric
computing,
is
reading
the
source.
Do
your
homework
right
know
what
you're
buying
before
you
buy
it.
A
This
is
all
really
sad
and
a
bit
unfortunate,
but
people
have
identified
this
problem.
People
have
there
are
people
within
the
community.
In
fact,
there
are
a
few
at
this
conference
if,
tomorrow
or
tomorrow
afternoon,
you'll
see
a
talk
by
Nicola.
Who's
worked
very
extensively
on
bringing
math
JavaScript
as
Phil
Burkart
and
then,
as
well
as
myself,
and
a
project
that
we've
been
working
on
for
the
past
year
and
a
half
is
called
standard,
lip
that
basically
aims
to
provide
very
high
performance
and
rigorous
and
precise
algorithms
for
doing
numeric
computing
streams
and
utilities.
A
If
you're
interested
in
it
go
to
standard
Lib
deus
standard
lib
and
if
you
want
to
take
a
that's,
a
quick
peek,
what
you'll
find
in
is
you'll
find
a
lot
of
your
different
implementations
that
you
might
expect
out
of
a
standard
library,
everything
from
trigonometric
functions,
special
order,
functions,
utilities,
random
number,
generators,
working
with
distributions
and
streams,
etc.
Even
some
machine
learning
stuff
in
there
at
the
present
moment.
So
definitely
take
a
look.
A
A
Instead
of
just
short
right
now,
it's
really
geared
toward
graphics
primitives,
rather
than
doing
numeric
computing
parallelism
right,
so
better
lightweight,
multi,
multi-threading
right
right
now,
it's
quite
heavy
because
you
have
to
do
multi
process
stuff
so
doing
parallel.
Computing
is
a
bit
tricky,
yeah,
better
primitives
for
GPGPU
and
then
also
big
float
big
end
support,
because
once
you
can
do
that,
then
you
can
start
doing
arbitrary-precision
arithmetic
so
with
that
I
just
want
to
say.
Thank
you.
A
I
definitely
come
up
with
how
many
questions
there's
stickers
here,
if
you
want
those
following
github
fall
on
Twitter
later
this
afternoon,
there'll
be
a
talk
at
4:40
by
Philip
Burkhart
on
real-time
machine
learning
and
nodejs.
I
definitely
attend
that.
If
you
want
to
know
a
bit
more
in
terms
of
how
you
can
do
math
and
numeric
computing
and
JavaScript
about
that.
Thank
you
very
much.