Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test and Make GEKPLS Compatible for 32-Bit Floats and Other Types #364

Open
vikram-s-narayan opened this issue Jun 27, 2022 · 0 comments
Open

Comments

@vikram-s-narayan
Copy link
Contributor

vikram-s-narayan commented Jun 27, 2022

The system is currently tested for matrices with 64-bit floats.

Test scenarios where the system errors or fails test cases when input matrices have 32-bit element types.

For context please refer to the PR review and reviewer comment below:

"
For now retain Float64, sure. But,

my concern is that an input matrix with 32-bit elements will result in poor performance without users knowing why this might be happening.

Are you sure that's the case for literally every example? I'd be surprised if there isn't a use case for it. It's most likely dependent on the condition number of some matrix in there. https://github.com/SciML/Surrogates.jl/pull/359/files#diff-a93d51ba639297205f811291f4c3ababde740f5a2532e4f74fb9ea3fa1387e93R448 most likely using QR on an ill-conditioned matrix is what would cause Float32 to give poor results, so it's probably connected to this comment.

But besides, that's not the only other number type. Dual numbers make sense for forward-mode AD of the whole surrogate, I can think of a few applications for that. BigFloat for higher precision. etc.

Originally posted by @ChrisRackauckas in #359 (comment)

"

@vikram-s-narayan vikram-s-narayan changed the title Test GEKPLS for 32-Bit Floats and Other Types Test and Make GEKPLS Compatible for 32-Bit Floats and Other Types Jun 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant