I wonder how it happened that the inner loop here ( https://github.com/oliverphilcox/Keplers-Goat-Herd/blob/3a0b... ) with N_it=5 is 2 times slower than the inner loop here ( https://github.com/oliverphilcox/Keplers-Goat-Herd/blob/3a0b... ) with N_it=18. It doesn't look two times faster at all, and I've spent a lot of time optimizing numerical code. Is it possible that the compiler managed to vectorize the faster loo…
I see a lot of sin's and cos's in both of those, and SSE and AVX don't have either of these operations for vectors. So I doubt it is that.
In numerical code the distinction between exact closed-form solutions and approximate solutions (through Newton's method and the like) is just not that meaningful. What determines speed is how much arithmetic you have to do, and it's quite possible to have a closed-form solution that is too cumbersome to evaluate compared to an approximate method. After all, approximate methods only have to converge to tolerance, nob…
Yes, well put. I'd take it further - in numerical code there is no real distinction /at all/ between closed form vs iterative solutions. Every type of numerical code is subject to truncation error; an iterative method with few moving parts may systematically converge to a more accurate result than the direct expression of a closed-form solution. It's quite interesting to delve into how special functions like `sin` an…
> I'd take it further - in numerical code there is no real distinction /at all/ between closed form vs iterative solutions.
This assertion is however wrong. Closed form solutions at worse accumulate rounding errors of a single expression, while iterative solutions not only pile on rounding errors throughout the iterations but they also have to stop by truncating the rest of the solution, leading to results which not only is approximate but also amplifies rounding errors.
Yes, well put. I'd take it further - in numerical code there is no real distinction /at all/ between closed form vs iterative solutions. Every type of numerical code is subject to truncation error; an iterative method with few moving parts may systematically converge to a more accurate result than the direct expression of a closed-form solution. It's quite interesting to delve into how special functions like `sin` an…
> I'd take it further - in numerical code there is no real distinction /at all/ between closed form vs iterative solutions. This assertion is however wrong. Closed form solutions at worse accumulate rounding errors of a single expression, while iterative solutions not only pile on rounding errors throughout the iterations but they also have to stop by truncating the rest of the solution, leading to results which not…
This is false, and your description of how to analyze/compare errors of iterative algorithms is also wrong. In short, if you have an algorithm with error n*eps compared to m*eps+tol, there's no a priori reason why one would be greater/equal to/smaller than another, it's just an overgeneralization (because you don't know yet what m,n,tol are). Focussing on truncating the rest of the solution is also wrong because that makes you think of only some specific types of iterative algorithms, as if they all converge linearly/sublinearly or something. In this particular paper the closed form is given as a ratio of two integrals, and both integrals are evaluated approximately using a perfectly reasonable quadrature rule, suitably chosen, and that quadrature rule has a truncation error, and that error is small enough not to matter.