You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ref #98. Multi-output surrogates have been created for the following, and AD is confirmed to work as well:
NeuralSurrogate
InverseDistanceSurrogate
SecondOrderPolynomialSurrogate
RadialBasis
This PR is not planned to implement multi-output surrogate optimization. The only other surrogate which is interesting to implement is Kriging, but I will save that for a PR where I implement a Stheno back-end. That PR will also address #100 for Kriging.
This PR slightly changes the SecondOrderPolynomialSurrogate implementation to include all n choose 2 combinations of input dimensions.
This PR preserves the type of the flux model output. In other words, for a user to return a scalar from their ANN, they should write: model = Chain(Dense(2,1), sum) to explicitly reduce the model output to a scalar.
I currently don't plan on implementing the other surrogates (Lobachesky, etc.) as multi-output, but if there's interest I will. The rest follow the same pattern where each output is fit separately (at least to the extent I'm aware of). Those implementations would be fairly boilerplate, I believe.
Hmm, I'm currently seeing LoadError: ArgumentError: Cannot setindex! to -0.6390356103155185 for an AbstractFill with value -63.903561031551845.. I previously saw this when defining my own models in Flux v0.10, so I switched to Flux 0.9 and didn't have any issues. I'm not sure why it's cropping up here, and I'm also not sure how to address the root cause.
Oh wow, amazing work! When the PR will be ready to be merged I will open a good first issue for the implementation of the remaining easier multi out surrogates
Ok, replacing the explicit scalar output of flux models with Chain(Dense(2,1), first) instead of Chain(Dense(2,1), sum) makes this work on my setup for Flux v0.10
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ref #98. Multi-output surrogates have been created for the following, and AD is confirmed to work as well:
NeuralSurrogateInverseDistanceSurrogateSecondOrderPolynomialSurrogateRadialBasisThis PR is not planned to implement multi-output surrogate optimization. The only other surrogate which is interesting to implement is
Kriging, but I will save that for a PR where I implement a Stheno back-end. That PR will also address #100 forKriging.This PR slightly changes the
SecondOrderPolynomialSurrogateimplementation to include all n choose 2 combinations of input dimensions.This PR preserves the type of the flux model output. In other words, for a user to return a scalar from their ANN, they should write:
model = Chain(Dense(2,1), sum)to explicitly reduce the model output to a scalar.I currently don't plan on implementing the other surrogates (
Lobachesky, etc.) as multi-output, but if there's interest I will. The rest follow the same pattern where each output is fit separately (at least to the extent I'm aware of). Those implementations would be fairly boilerplate, I believe.