10:33 <_whitenotifier-9439> [Principia] pleroy commented on issue #1760: Deterministic floating-point arithmetic - https://github.com/mockingbirdnest/Principia/issues/1760#issuecomment-3094429332

10:33 <queqiao--> Reply to "C​la​ye​l: what actually is the mysterious issue 1760? i constantly see it mentioned in the descript..."

10:33 <queqiao--> <s​ic​he​lg​ai​ta​> I put some more context here: https://github.com/mockingbirdnest/Principia/issues/1760#issuecomment-3094429332.

11:47 <queqiao--> <Q​az​er​ow​l> Does it really matter that the returned result is mathematically correct as long as it's the same result across all platforms?

13:07 <queqiao--> <s​ic​he​lg​ai​ta​> Yes, otherwise you can never change your implementation. If you think of a smart optimization, you cannot do it because you will change the results.

14:18 <queqiao--> <Q​az​er​ow​l> But if you demanded perfect accuracy, you wouldn't be able to use that performant optimization anyway unless it happened to be perfectly accurate. And I assume exciting new perfectly-accurate optimizations for sin/cos don't pop up too often.

14:26 <queqiao--> <e​gg​> That really isn’t how any of this works.

14:28 <queqiao--> <e​gg​> A correctly rounded (that is a technical term, not « perfectly accurate ») implementation of a function is typically a pretty normal implementation of that function (still a good one, faithfully rounded, and correctly rounded for most inputs) paired with a test for a risk of misrounding and a slow path.

14:30 <queqiao--> <e​gg​> The performance of the slow path essentially doesn’t matter because it is a once-in-a-million thing. And the fast path is ordinary enough that the implementation tradeoffs change as they do for other implementations (between large or small tables, divisions vs. other operations, etc.).

14:35 <queqiao--> <e​gg​> So, e.g., Principia has 2 different implementations of a correctly-rounded cube root, depending on whether we can use FMA in the faithful fast path. And there are plenty of other options we have considered for that fast path; some of them might become more performant than the ones we currently use as architectures change.

14:56 <_whitenotifier-3b5f> [Principia] pleroy closed pull request #4248: Support for polynomials in relative/absolute error computation - https://github.com/mockingbirdnest/Principia/pull/4248

15:18 <queqiao--> <s​ic​he​lg​ai​ta​> "... as architectures change" is really important because architectures actually change all the time. Over the course of my career I have seen "don't use floating-point, do everything in integer" and then in sequence "use the x87 instructions they are pretty fast and pretty accurate", "don't use x87, use the native fp and use tables if they can save fp operations", "don't use tables, memory is slow and you have

15:18 <queqiao--> multiple fp units anyway", and at the moment the trade-off is "caches are so big that your table will be in the cache all the time, so tables are good again". I fully expect that the trade-offs will be different 5 years from now. (@egg also points out "division bad", "division good", "division bad", "division good".)