Long story short, NWChemEx needs DFT grids that work with arbitrary floating point (FP) types. We'd like to use IntegratorXX, but AFAIK the current blockers are:
-
constexpr tables for angular components only work for literal FPs. It's fine to store the tables as double or whatever, but there needs to be some logic that will convert them to the user's specified FP type. Solution would be to run them through some template meta-programming to figure out if we use the table directly or if we need to convert them.
-
The use of std::exp and the like. Custom FPs often provide their own versions of the transcendental functions, we'd either need to remove the std:: and rely on argument dependent lookup (assuming the custom FP use the same signature) or write traits classes that can be customized by the user to control what gets called (default implementation uses ADL). IMHO the traits class is the better option.
-
There are std::is_floating_point_v gates on the quadrature_traits<MuraKnowles<PointType, WeightType> that would need to be removed.
-
Literals, i.e., expressions like x + 1.0. I think it's reasonable to assume custom FP will define operator+(double), but there may be places where wrapping 1.0 as T(1.0) is needed (if going with traits for 2, can just make a method for converting double objects).
-
Somewhat ironically, the Gauss-Legendre Newton iterations need to be pinned to a literal floating-point type like double and the result converted to the custom FP type. The iterations are ultimately an auxiliary calculation to find a root. It's the value of the root, not how it was obtained, that the grid cares about. Thus, for the custom FP types I'm worried about, we don't want the FP type to enter into the iterations.
I need to make these changes for IntegratorXXX to work for us. My question is once I've made these changes: are you interested in having them contributed back?
Long story short, NWChemEx needs DFT grids that work with arbitrary floating point (FP) types. We'd like to use IntegratorXX, but AFAIK the current blockers are:
constexprtables for angular components only work for literal FPs. It's fine to store the tables asdoubleor whatever, but there needs to be some logic that will convert them to the user's specified FP type. Solution would be to run them through some template meta-programming to figure out if we use the table directly or if we need to convert them.The use of
std::expand the like. Custom FPs often provide their own versions of the transcendental functions, we'd either need to remove thestd::and rely on argument dependent lookup (assuming the custom FP use the same signature) or write traits classes that can be customized by the user to control what gets called (default implementation uses ADL). IMHO the traits class is the better option.There are
std::is_floating_point_vgates on thequadrature_traits<MuraKnowles<PointType, WeightType>that would need to be removed.Literals, i.e., expressions like
x + 1.0. I think it's reasonable to assume custom FP will defineoperator+(double), but there may be places where wrapping1.0asT(1.0)is needed (if going with traits for 2, can just make a method for convertingdoubleobjects).Somewhat ironically, the Gauss-Legendre Newton iterations need to be pinned to a literal floating-point type like
doubleand the result converted to the custom FP type. The iterations are ultimately an auxiliary calculation to find a root. It's the value of the root, not how it was obtained, that the grid cares about. Thus, for the custom FP types I'm worried about, we don't want the FP type to enter into the iterations.I need to make these changes for IntegratorXXX to work for us. My question is once I've made these changes: are you interested in having them contributed back?