[HN Gopher] Math Keeps Changing
___________________________________________________________________
Math Keeps Changing
Author : jashkenas
Score : 35 points
Date : 2020-02-16 19:23 UTC (3 hours ago)
(HTM) web link (macwright.org)
(TXT) w3m dump (macwright.org)
| 32gbsd wrote:
| I never understood why PHP gets so much hate but Javascript gets
| a pass. maybe times are a changing. But it might even be too late
| for PHP.
| m4r35n357 wrote:
| Expecting a cobbled together mess to do accurate arithmetic.
| There's your problem.
| 0xff00ffee wrote:
| I'm really tired of articles bemoaning the author's recent
| discovery of something called "floating point math". Are they
| actually going to college? Are they paying attention to their
| CompSci classes? Is it really worth writing another blog article
| about the exact same thing we've seen multiple times on HN in the
| past month alone?
|
| The moral of the story should be "Pay attention in school." And
| not "everyone is winging it [so here's a blog so I feel better
| about winging it]". Because in fact, a lot of us are NOT winging
| it, we are working very very hard to learn.
|
| EDIT: If you want an implementation of these functions to fit
| your needs, perhaps understand your problem a little better and
| define your needs, such as precision and tolerance and speed and
| memory usage. You know: engineering work. There are literally a
| dozen algorithms a google away or in an actual book. We've been
| computing these functions for over 60 years electronically (and
| longer analog), and I guarantee there is an implementation that
| fits your constraints.
| titzer wrote:
| > We've been computing these functions for over 60 years
| electronically (and longer analog), and I guarantee there is an
| implementation that fits your constraints.
|
| While I mostly agree with your comment (and upvoted you), I
| think the main problem the author runs into is that
| Javascript's Math library is _underspecified_ in a bad way. The
| trig functions have precision that is really only held up by
| Web Reality, meaning the least precision that the bulk of
| websites can function under before something breaks and someone
| starts complaining.
|
| I saw this firsthand. I worked on V8 during the time a number
| of precision-altering changes were made to its implementation
| of Math.*. Some had to be reverted because websites did indeed
| misbehave.
|
| Compare this to e.g. Java, which specifies that all math
| functions in its standard library are accurate to 1up.
|
| Math keeps changing because Javascript's spec is weak.
| soVeryTired wrote:
| So how would you calculate the sine function? Exactly how?
| 0xff00ffee wrote:
| > Exactly how?
|
| Are you being sarcastic?
|
| EDIT: Assuming you aren't being sarcastic, you clearly aren't
| thinking like an engineer. As the OP points out, there are
| many ways to compute sine. And they all have tradeoffs. So
| you need to decide what tradeoffs describe your constraints.
| Otherwise you can simply use an infinite series. See, you
| didn't define what you meant by "exactly". Exactly to
| infinite precision? Or exactly in 100 clock cycles?
| soVeryTired wrote:
| The point of the article is that the fine details of the
| calculation of transcendetal functions often change between
| javascript versions. The standards committee -- possibly
| deliberately -- didn't pin them down tightly.
| 0xff00ffee wrote:
| I'll repeat once again: do your engineering homework and
| decide if you can live with a spec that changes the Nth
| digit of precision, or if you need more precision roll
| your own. If you're just making an SVG rotate, then why
| are you arguing?
| zamadatix wrote:
| The Nth digit in this case is digit 0, as the article
| points out. You're interpreting it as the usual "floating
| point is inaccurate" article/conversation instead of what
| it actually is - a surprising detail in the ECMAScript
| standard.
| saagarjha wrote:
| Using a Taylor series, usually.
| roywiggins wrote:
| It's not floating point's fault exactly. Seems to me it's that
| these implementations are less accurate than the number of
| digits they're returning. You could get a similar thing with
| fixed point arithmetic.
| [deleted]
| [deleted]
| zamadatix wrote:
| Your edit is basically what the article talks about, not what
| you ragged on it for.
| 0xff00ffee wrote:
| I'm ragging on it for its banality.
|
| "ragging". My favorite 80's term.
| ripley12 wrote:
| Did you read the entire article? The author says that floating
| point math is both 1) fine 2) not the cause of the issue under
| discussion. Floating point is a tiny digression in a much
| larger piece.
|
| > Floating point arithmetic might be weird, but it's very
| consistent and well-specified: the IEEE 754 specification is
| rigorously implemented. So it's not arithmetic...
| archgoon wrote:
| JS Standards compliant implementations of some math functions:
|
| https://tc39.es/ecma262/#sec-math.sin function
| sin(x) { if (x == -Infinity || x == Infinity) return NaN;
| return x; } function cos(x) { if (x ==
| 0) return 1; return sin(x); } function
| sqrt(x) { if (x < 0) return NaN; return x;
| } function exp(x) { if (x == -Infinity)
| return 0; if (x == Infinity) return x; return
| cos(x); }
| rcar wrote:
| That's a pretty generous interpretation of
|
| > implementation-dependent approximation to the sine of x
| jcranmer wrote:
| If you don't care what the error is, then 1 is a perfectly
| acceptable answer. I have no clue what the error on that
| answer is, but you said you didn't care about that, so...
|
| That said, sin(x) being about x for "sufficiently small" x
| (about 0.1 or less) is a very well approximation. The error
| bound is given by the Maclaurin expansion of sin(x), which is
| x - x3/3! + x5/5! - ..., so sin(x) = x has an error bound of
| x3/6.
| thaumasiotes wrote:
| > If you don't care what the error is, then 1 is a
| perfectly acceptable answer. I have no clue what the error
| on that answer is
|
| I can help! The error is at most 2. ;D
|
| > The error bound is given by the Maclaurin expansion of
| sin(x), which is x - x3/3! + x5/5! - ..., so sin(x) = x has
| an error bound of x3/6.
|
| I want to note that this is only true for small x. In
| general, the Maclaurin sequence is not absolutely
| decreasing (that is, the sequence formed by the absolute
| value of each term is not strictly decreasing -- x5/5! >
| x3/3! when x > 5), so the first unused term is not a strict
| bound on the total error.
| twic wrote:
| I am absolutely appalled by those unnecessary semicolons.
| melling wrote:
| With Data Science and Machine Learning, my interest in math has
| greatly increased too. There's definitely more of a need.
|
| I'm working my way through this book:
|
| https://www.amazon.com/Data-Science-Scratch-Principles-Pytho...
|
| by rewriting the examples in Swift:
|
| https://github.com/melling/data-science-from-scratch-swift
|
| I do like the author's idea of creating his Simple Statistics
| library:
|
| https://macwright.org/2012/06/26/simple-statistics.html
|
| You definitely learn much more by building something, even if
| it's less than perfect.
| zozbot234 wrote:
| AIUI, the IEEE 754 standard does _not_ guarantee exactly-
| reproducible results for transcendental operations, because of
| the "table-maker's dilemma" - the mathematical fact that given a
| result that's arbitrarily close to being halfway in-between two
| floating-point values that differ by one ulp (unit in the last
| place)[0], it may be computationally infeasible to determine the
| "correctly" rounded result. So this outcome, while perhaps
| undesirable from an intuitive POV, is not "wrong" in any real
| sense.
|
| [0] Assuming round-to-nearest, of course. For directed rounding,
| the problematic case is a result that's arbitrarily close to some
| exactly-representable value, but not yet determined to be "apart"
| from it or not in the rounding sense.
| saagarjha wrote:
| > JavaScript, on Twitter, gets a lot of heat for this behavior
| 0.1 + 0.2 = 0.30000000000000004
|
| I mean, there's a lot of things JavaScript should get heat for,
| but this really shouldn't be one of them. This is inherently an
| issue with any language that has floating point numbers.
|
| > And this is the way that compiled languages have always worked:
| when you compile a C program, the methods you import from math.h
| are included in the compiled binary.
|
| Depends on your inlining level and choice of linking.
| chongli wrote:
| _This is inherently an issue with any language that has
| floating point numbers._
|
| It's not an issue for languages that have floating point
| numbers, it's an issue for languages that make them the default
| (or worse, the only option). There are plenty of other
| languages that let you use arbitrary-precision integers or
| decimals as well as the usual fixed-size floats and integers.
|
| When you're writing a program intended to provide calculations
| to the end user (such as a calculator) you really ought to use
| arbitrary-precision decimals so that you never run into this
| problem.
| thaumasiotes wrote:
| > (such as a calculator)
|
| I'd be interested in a calculator that used arbitrary-
| precision decimals to compute arcsines, logs, etc. But I
| wouldn't recommend anyone create or use one.
| jcranmer wrote:
| The use of arbitrary-precision decimals instead of floats
| comes with a _very_ severe performance penalty. And for what
| benefit? So you can represent values to a greater precision
| than your ability to measure them accurately?
|
| Almost anything you'd want to use a non-integer number for is
| going to be difficult to nail down to 5 or 6 decimal digits
| of precision on (honestly, even 3 is pushing it). Double-
| precision floats gives you 11 decimal digits of precision--
| ample room for accumulated round-off error to not affect the
| final result, unless you've got numerical instabilities.
| saagarjha wrote:
| Doubles give you around 15-16 (according to DBL_DIG) digits
| of precision, don't they?
| jcranmer wrote:
| You're right, I mixed it up with the 11 bits of exponent.
| ripley12 wrote:
| > I mean, there's a lot of things JavaScript should get heat
| for, but this really shouldn't be one of them. This is
| inherently an issue with any language that has floating point
| numbers.
|
| This is mentioned in the paragraph that is immediately after
| the text you excerpted.
| saagarjha wrote:
| I'm calling out Twitter explicitly, not the author, because I
| don't think he does so enough.
___________________________________________________________________
(page generated 2020-02-16 23:00 UTC)