-
Notifications
You must be signed in to change notification settings - Fork 33
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
Type of vectors for aggregated losses overly restrictive? #109
Comments
Did you try If I remember correctly the reason the offending method has the ... ($($FUN)).(Ref(loss), target, output)::Array{S,$(max(N,M))} ... line, was that broadcast lead to failed return type inference. this was quite a while ago, so might be that we can just remove the |
Thanks for that workaround, which works. If someone can check the necessity of the typing that would be great. |
@ablaom can you please double check that this issue is still valid in the latest master version? I refactored the entire package months ago to cleanup the type annotations, etc. If the issue persists, can you propose an improvement as a PR? |
Very sorry @juliohm, but I just don't have the bandwidth right now to work on LossFunctions.jl. My post includes a MWE, which should be easy enough to check. |
This shouldn't be an issue in the latest version. Now the loss function objects only accept scalars as input, and users are expected to use broadcasting to obtain the vector of losses, or the function |
It seems I can't use the loss functions in this package for either SparseVectors or Flux's tracked vectors. Is there a good reason why a general
AbstractVector{<:Number}
is not allowed?The text was updated successfully, but these errors were encountered: