Closed susilehtola closed 1 year ago
I'm not a fan of keeping around precomputed grids which can take an arbitrary npts
input (e.g. GC, GL, etc). For some (e.g. Gill's MultiExp
) it can't be (practically) avoided, so I'm fine tabulating those. The reason we tabulate the angular quadratures is that they're hard to compute. Computing these quadratures is trivial, so this wouldn't be a necessary performance optimization and would increase compile times, etc.
Your point regarding precision is well taken - I would opt to simply have a path that computes the nodes/weights in multiple / arbitrary precision programatically. There are C/C++ libraries that can do this (GMP comes to mind, but its GPL...). All the functions are templated, so it should be relatively straightforward to do.
We can definitely track that if there's an immediate use case (maybe for the unit tests as you suggest?)
The angular grids are precomputed and stored statically.
I wonder whether it would make sense to also precompute the primitive quadratures, since this could be done in arbitrary precision with e.g.
sympy
.Storing the weights and nodes for $n$ points costs $2 n$ floating point numbers. This means that storing all rules from $n=1$ to $N$ costs $(N+1)^2 - N -1$.
It might be a good idea to to have this functionality anyway, since one should test the accuracy of the computed nodes and weights by comparison to accurate reference values.