If you ignore the problem then the problem indeed goes away. The need for distinguishing very small epsilon exists because of the continuity assumption, and because of the continuity assumption you can't really solve it either.

> Then we can decide to go left if it tells us x < 0.5, and right if it tells us unsure or that x >= 0.5.

Now you just moved the problem to deciding at which point you are unsure. As long as there is a decision to take the issue persists, it's only if you always go left (or always go right) that the issue doesn't exist.

That's perfectly valid, when one knows a specific step or result must be positive or negative.

Not that much different from dimensional analysis, which speedruns you to get/fix to proper formula (at the cost of skimming on dimensionless constants).

Similarly, interviewer was not impressed when they cut me short and started walking me through some step and I pointed to them that their result was obviously wrong as it was dimensionally inconsistent and if they didn't cut me out the formula must have been something like baz*foo/bar^2 or something and now we just have to figure out the constants.

Tricky maths and just-as-tricky implementation. And a broken implementation can obviously make the best maths worthless.

Yeah, that's what most of us think initially. The problem is that the effects of error can compound in many ways -- nonlinearities, feedback, etc. can all wreck your accuracy enough to make the results meaningless.

A really instructive counterexample for me was solving quadratics. Easy, right? Just try writing a solver for ax^2 + bx + c = 0. Now try breaking it. If all you did was use the quadratic formula, you should find that it's quite easy to break it, and surprisingly difficult to write a robust solver. (If you're completely stuck, consider the most obvious edge case: what if a ˜ 0? Any other scenarios you can think of?)

that's sort of ridiculous. Would he be more ok with the output 0.48? what about 0.51? Ironically, in the age of LLMs and non-deterministic output, maybe he would.

Scientific computation.

I'm not even sure, it is a trade-off between (computational) speed and accuracy.

In my experience, error-analysis was a mandatory course for physics, but not in robotics. The error analysis was manual and time-consuming.

In robotics, no one cared why it occasionally produced NaNs, etc.. people just added a small number here and there.

That's faster to program.

To put it more positively, I think, the view here is more having an application, which is robust in the face of errors / edge cases. What counts is the output (action).

While in science the correct model is part of the output. Edge cases are an important part of it.

This is a bit of an oversimplification as well, it's not like you keep multiplying pi with itself over and over again and it's not like the error you introduce is random, if you've rounded pi once, you're gonna keep make a slight error in the same direction.

If you were right there'd be no hope of ever getting sane results when multiplying largish matrices of doubles regardless of the presence of pi.

I'm not saying that accumulation of error doesn't exist, I'm just saying that it's not to the extremes you're describing.

Because there is no "end". These are infinite series.

> But I might as well leave the leading Zero out and argue that:

Yes, exactly, that's the whole point. You cannot manipulate non-convergent series in this way if you want consistent results.

Not if they come in as integers that have to be coerced at some point.

>What is the library supposed to do?

Compare ad to bc instead of ad - bc to zero, for one.

>This is a great example of the fallacy of believing that a library automatically solves arbitrary issues.

I didn’t say that and don’t believe it. My point only depends on he library having avoided more domain-specific rookie mistakes than I would have caught in five minutes, when it comes to computational linear algebra. Like the sibling commenter, I don’t think libraries are a panacea, and the answer depends on the specifics of the case.

Yes, that's the obvious part.

I might have a solution for that : I work on methods to both quantify the impact of your precision on the result and locate the sections of your code that introduced the significant numerical errors (as long as your numeric representation respects the IEEE standard).

However, my method is designed to test or debug the numerical stability of a code and not be used in production (as it impacts performances).

Not really when the code is routinely transcribed from papers, and the ages-old convention throughout mathematics is one-based indexing, both bounds of the interval included. (With the notable exception of Euler’s beta and gamma functions.) Of course, in a paper intended for a human reader the occasional off-by-one error is much less dire than in code, so the author is freer to use a more error-prone convention.

I once had to translate from a one-based paper to zero-based Python code (with the added bonus of different discrete Fourier conventions *shudder*), and it’s remarkably annoying even if the resulting code is more obviously correct than the paper’s original formulas.

I totally agree. To me, there are 2 kinds of algorithms that one should get used to. 1. is computing fast enough (that doesn't mean super fast, but sometimes it means hours instead of months), and 2. is spotting out errors, both evident and subtle.

This said, I'm certainly not in the set of great mathematicians.

Since you know, computers are famously bad at iterating. (Hint: they are not)

>a bad choice for most scientific computation

Is weird this. Scientific computation is at most a niche.

Financial and real-world decimal calculations is the norm.

That is why a lot of people could be server better by the use of decimals or fixed point.

Yeah, but then you're having to learn all the special cases for when it silently gives wrong answers, and hope to hell that you didn't miss any.

Much better to have consistency and behave the same way all the time, than to optimise for 3 keystrokes and introduce all sorts of special exceptions that the programmer must memorise.

Having your share of holiday costs come out as NaN is fiddlier than getting an exception at the point where you actually divided by zero.

If you were working with polynomial coefficients, Fast Fourier Transforms and convolutions, or modulo arithmetic, you'd prefer zero based arrays. In my experience, the majority of places where math notation uses 1-based arrays are in applications where the index doesn't matter.

I prefer zero based arrays specifically because they are better for doing mathematics. Yeah, it sucks that a lot of matrix algorithms in text books use one based arrays, but I blame the text book for getting it wrong.

Mostly false; see https://www.cs.berkeley.edu/~wkahan/Mindless.pdf

It is true that an arbitrary, independent sequence of n floating point operations can potentially lose up to 2n bits of precision. However, it is false that most scientific computing code has such structure. On the contrary, the loss of precision in numerical algorithms can be estimated quite well using standard techniques of error analysis, especially when there is underlying matrix structure to exploit. The growth of error in properly written numerical code should NOT grow exponentially with the number of floating point operations. It should be bounded by intrinsic properties of the underlying matrix, such as its condition number or spectral norm.