6 ms·
Large Multiplication
- cperciva 3y agoIt is difficult to prove that round-off error won't affect the results. Colin Percival, Rapid multiplication modulo the sum and difference of highly composite numbers, Mathematics of Computation, Volume 72, Number 241, Pages 387-395, 2002.
- Strilanc 3y agofrom google scholar search: https://www.ams.org/journals/mcom/2003-72-241/S0025-5718-02-01419-9/S0025-5718-02-01419-9.pdf https://www.ams.org/journals/mcom/2003-72-241/S0025-5718-02-...
- cperciva 3y agoRight, I didn't think people would actually want to read the paper; I just wanted to make the point that, rather than being difficult, this was solved over 20 years ago. (And I was an undergrad at the time!)
- CodesInChaos 3y agoThe article claims that the provable bounds for rounding errors are significantly worse than the empirical bounds used by y-cruncher, so an provably correct algorithm would not have competitive performance. I'm not sure if you claim that the bounds proven in your paper are tight enough to be competitive, or if you simply confirm that there are slower conservative implementations that are provably correct.
- fdej 3y agoThis is indeed the issue. Using provable bounds loses too many bits for complex FFTs to make sense for long multiplies.
- cperciva 3y agoI (a) proved bounds, and (b) showed that those bounds were tight by constructing inputs which came close to the error bounds. The "empirical bounds" demonstrably don't work for some inputs.
- moonchild 3y agoI'm not familiar with the domain, but is there a particular reason for using floating-point numbers other than that they have faster hardware support? It is not hard to synthesise a fast integer multiply from a float fma, and then the rest of the algorithm can be phrased in terms of that.
- cperciva 3y agoDoing an FFT with integer math means doing it in a ring -- and thus dealing with modular reduction. Using complex floating-point math the "modular reduction" comes for free thanks to w^N=1. I would have to write some code to confirm which is faster today -- especially if you choose rings which make the modular reduction easier -- but CPUs have typically optimized FP math more for throughout than integer math, since mostly-integer code has more unpredictable branches and less ILP than FP-heavy code.
- Aardwolf 3y ago> Large integer multiplication isn't the only place in y-cruncher that uses floating-point for otherwise integer tasks. This sort of stuff is littered all over the entire program. The most brutal example of this is in the Digit Viewer's binary-to-decimal conversion routine. Does anyone know more about this, which floating point algorithm is used for base conversion here? The link in the article to github is broken, and when searching in the github repository history the code isn't well documented to tell which algorithm it is.
- 0xf00ff00f 3y agoTIL: there are compiler intrinsics for add-with-carry. https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/addcarry-u32-addcarry-u64.html https://www.intel.com/content/www/us/en/docs/cpp-compiler/de...