| 00:11 | <bakkot> | new question: should Math.sum do kahan summation |
| 00:11 | <bakkot> | acceptable answers are "yes" and "of course" |
| 10:50 | <Jack Works> | https://github.com/terser/terser/blob/master/test/compress/labels.js#L84-L104 |
| 10:51 | <Jack Works> | Does anyone know why? These two codes have the same observable semantics to me |
| 14:40 | <Justin Ridgewell> | That could be changed |
| 15:56 | <Michael Ficarra> | yes, but there's basically an unlimited number of variants of Kahan's that track an additional N compensation vars, so what should our N be for a reasonable precision/perf trade-off? |
| 15:56 | <Michael Ficarra> | something like 3 is probably ideal |
| 15:58 | <bakkot> | my vote is to just do whatever Python does |
| 15:58 | <bakkot> | for fsum |
| 15:58 | <bakkot> | which appears to be... 32 |
| 15:59 | <bakkot> | https://github.com/python/cpython/blob/a241003d048f33c9072d47217aa6e28beb7ac54f/Modules/mathmodule.c#L1284 |
| 15:59 | <bakkot> | 32 might be overkill... |
| 16:00 | <Michael Ficarra> | holy crap, 32?! |
| 16:04 | <bakkot> | java uses just the basic (one partial) kahan if I'm reading this right https://github.com/openjdk/jdk/blob/e8271649e00771a8bbee240aa1bbbc27a672b22a/src/java.base/share/classes/java/util/stream/Collectors.java#L717 |
| 16:08 | <bakkot> | ok no python uses an unbounded number of partials |
| 16:08 | <bakkot> | that's wild |
| 16:08 | <bakkot> | they do this so that it's actually correct |
| 16:08 | <bakkot> | like, actually correct, not just bounded error |
| 16:09 | <bakkot> | https://code.activestate.com/recipes/393090/ |
| 16:09 | <bakkot> | while attractive I think that probably is in fact overkill |
| 16:10 | <Michael Ficarra> | I mean, I'm up for it if implementers are |