[ogogmad]

Related: In numerical analysis, I found the distinction between forwards and backwards numerical error to be an interesting concept. The forwards error initially seems like the only right kind, but is often impossible to keep small in numerical linear algebra. In particular, Singular Value Decomposition cannot be computed with small forwards error. But the SVD can be computed with small backwards error.

Also: The JSON example is nasty. Should IDs then always be strings?

[deathanatos]

> The JSON example is nasty.

Specs, vs. their implementations, vs. backwards compat. JSON just defines a number type, and neither the grammar nor the spec places limits on it (though the spec does call out exactly this problem). So the JSON is to-spec valid. But implementations have limits as to what they'll decode: JS's is that it decodes to number (a double) by default, and thus, loses precision.

(I feel like this issue is pretty well known, but I suppose it probably bites everyone once.)

JS does have the BigInt type, nowadays. Unfortunately, while the JSON.parse API includes a "reviver" parameter, the way it ends up working means that it can't actually take advantage of BigInt.

> Should IDs then always be strings?

That's a decent-ish solution; as it side-steps the interop issues. String, to me, is not unreasonable for an ID, as you're not going to be doing math on it.

[gugagore]

IIRC, forward error: the error between the given answer and the right answer to the given question.

Backward error: the error between the given question, and the question whose right answer is the given answer.

Easier to parse like this: a small forward error means that you give an answer close to the right one.

A small backward error means that the answer you give is the right answer for a nearby question.