provide a cmake c++17 switch
to not depend on the std_backport
change those lines from 11 to 17 conditional to a global define
https://github.com/mlpack/mlpack/blob/de94eee6881e33f1145d9d4a8b5380a5be8af36a/CMakeLists.txt#L
Current implementation of join can be improved by performing the operation in a single call to the backend kernel instead of multiple calls.
This is a fairly easy kernel and may be a good issue for someone getting to know CUDA/ArrayFire internals. Ping me if you want additional info.
Currently spack does not support the following packages, all of these packages are installed outside of Spack at Cori, we would like to get support for these packages if possible.
Add #[track_caller] to some panicking methods. Slicing methods seem the most prudent (Index/Mut does not apply, sorry).
Needs benchmarks to investigate impact, preferably holistic benchmarks.
Now that we've made BLAS support optional on several linfa crates, we should compare the performance of those crates with and without BLAS. Doing this requires those crates to have a complete set of benchmarks that represent realistic workloads. If BLAS turns out to have no performance improvements, we can even remove BLAS support, improving code quality.
Benchmark status for each crate that
CDash has builds with C++17 enabled, but they are not triggered when github builds opened PR's.
It would be great to have at least one build (gcc or clang) in github wih C++17.
https://llvm.org/docs/NewPassManager.html
The tricky part is to keep our custom command line options working.
using the approach laid out in:
dswah/pyGAM#154
Add a description, image, and links to the scientific-computing topic page so that developers can more easily learn about it.
To associate your repository with the scientific-computing topic, visit your repo's landing page and select "manage topics."
Deprecated in documentation only since scipy/scipy#11304
CC @ilayn