5 ms·

That's a pretty generous interpretation of > implementation-dependent approximation to the sine of x

by rcar 7y ago

jcranmer 7y ago
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 - x³/3! + x⁵/5! - …, so sin(x) = x has an error bound of x³/6.
- thaumasiotes 7y ago
  > 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 - x³/3! + x⁵/5! - …, so sin(x) = x has an error bound of x³/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 -- x⁵/5! > x³/3! when x > 5), so the first unused term is not a strict bound on the total error.
- im3w1l 7y ago
  It sounds like you come from the C++ world, where the compiler is basically an adversary playing gotcha games. But the web has a different culture where webpage and user agent collaborate. Scripts try to account for browser bugs, and browsers try to render even syntactically invalid pages.
  - jcranmer 7y ago
    Actually, my inspiration came from a story I heard (thirdhand) about a numerical analysis professor who would give that response, set around 1970--before C existed, let alone C++.
    - im3w1l 7y ago
      People obviously care about the error, to some extent, in the javascript world, and browser makers understand that and would never do something as stupid as you propose even if it might technically be allowed. What they might not care about is the provenance of your jokes.
      - jcranmer 7y ago
        Contrary to what you believe, no programming language community (not even C/C++) would consider such a loose interpretation of the standard to be a valid implementation. The point of the parable is that, since the standard would seem to admit such a ludicrously incorrect implementation, the standard itself must be wrong. I will point out, since you appear to believe contrarily, that my experience is that the JS and browser engine community have historically been far more accepting and blasé about loose specification than the C/C++ community.
        lmm 7y ago
        > Contrary to what you believe, no programming language community (not even C/C++) would consider such a loose interpretation of the standard to be a valid implementation. Really? It doesn't seem obviously worse than deleting null pointer checks as C/C++ compilers do, which is widely accepted.
        jcranmer 7y ago
        What people forget is that, if the compiler didn't delete the null pointer checks and executed the semantics exactly as the programmer wrote them... the program is guaranteed to crash. Most of the complaints of undefined behavior are actually people who write code with nonsense semantics, and are then surprised to find that the compiler comes out with a different nonsense semantics than what they intended.
        lmm 7y ago
        Failure semantics are just as important as happy-path semantics. Good languages are fail-stop. The case I'm thinking of was some linux kernel code that looked roughly like: void checkBeforeDangerousThing(SOMETHING* detailsPtr) { SOMETHING details = *detailsPtr; if(detailsPtr == null) return; if(!isValid(details)) return; doDangerousThing(); } The intended semantics of that are pretty clear. There are two defensible implementations for this code if detailsPtr is null (hence why it was left undefined in the C standard): either it should return cleanly without calling doDangerousThing, or it should trap on the invalid null pointer dereference (possibly asynchronously). What no reasonable language community would consider to be a reasonable implementation - what only an adversarial reading of the standard reveals is even an option - is to execute doDangerousThing() when passed a null pointer.

That's a pretty generous interpretation of > implementation-dependent approximation to the sine of x

by rcar 7y ago

That's a pretty generous interpretation of > implementation-dependent approximation to the sine of x

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 - x³/3! + x⁵/5! - …, so sin(x) = x has an error bound of x³/6.

thaumasiotes 7y ago
> 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 - x³/3! + x⁵/5! - …, so sin(x) = x has an error bound of x³/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 -- x⁵/5! > x³/3! when x > 5), so the first unused term is not a strict bound on the total error.
im3w1l 7y ago
It sounds like you come from the C++ world, where the compiler is basically an adversary playing gotcha games. But the web has a different culture where webpage and user agent collaborate. Scripts try to account for browser bugs, and browsers try to render even syntactically invalid pages.
- jcranmer 7y ago
  Actually, my inspiration came from a story I heard (thirdhand) about a numerical analysis professor who would give that response, set around 1970--before C existed, let alone C++.
  - im3w1l 7y ago
    People obviously care about the error, to some extent, in the javascript world, and browser makers understand that and would never do something as stupid as you propose even if it might technically be allowed. What they might not care about is the provenance of your jokes.
    - jcranmer 7y ago
      Contrary to what you believe, no programming language community (not even C/C++) would consider such a loose interpretation of the standard to be a valid implementation. The point of the parable is that, since the standard would seem to admit such a ludicrously incorrect implementation, the standard itself must be wrong. I will point out, since you appear to believe contrarily, that my experience is that the JS and browser engine community have historically been far more accepting and blasé about loose specification than the C/C++ community.
      - lmm 7y ago
        > Contrary to what you believe, no programming language community (not even C/C++) would consider such a loose interpretation of the standard to be a valid implementation. Really? It doesn't seem obviously worse than deleting null pointer checks as C/C++ compilers do, which is widely accepted.
        jcranmer 7y ago
        What people forget is that, if the compiler didn't delete the null pointer checks and executed the semantics exactly as the programmer wrote them... the program is guaranteed to crash. Most of the complaints of undefined behavior are actually people who write code with nonsense semantics, and are then surprised to find that the compiler comes out with a different nonsense semantics than what they intended.
        lmm 7y ago
        Failure semantics are just as important as happy-path semantics. Good languages are fail-stop. The case I'm thinking of was some linux kernel code that looked roughly like: void checkBeforeDangerousThing(SOMETHING* detailsPtr) { SOMETHING details = *detailsPtr; if(detailsPtr == null) return; if(!isValid(details)) return; doDangerousThing(); } The intended semantics of that are pretty clear. There are two defensible implementations for this code if detailsPtr is null (hence why it was left undefined in the C standard): either it should return cleanly without calling doDangerousThing, or it should trap on the invalid null pointer dereference (possibly asynchronously). What no reasonable language community would consider to be a reasonable implementation - what only an adversarial reading of the standard reveals is even an option - is to execute doDangerousThing() when passed a null pointer.