-
-
Notifications
You must be signed in to change notification settings - Fork 608
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
Make outputsize
understand multiple inputs
#1486
Conversation
f(rand(10,3)) is an error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No complaints from me. I like the more informative error message. We'll have to make sure it stays in sync with the actual implementation of Chain
, but I think it is worth it.
Great. As long as it still seems fast enough for your applications, that's one possible concern. It is only the outermost Chain, with no attempt to recurse into try/catch-ing sub-sub-layers. |
Good point, I'll double check the speed like we did on the original PR. But I think for its use case, a minor slowdown is fine for convenient errors. It doesn't need to be super fast, just faster than evaluating ResNet-101 (which this should be). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. Here are the benchmarks on a large model:
julia> m = densenet_121();
# this PR
julia> @benchmark Flux.outputsize($m, (256, 256, 3, 50))
BenchmarkTools.Trial:
memory estimate: 201.89 KiB
allocs estimate: 4546
--------------
minimum time: 402.313 ms (0.00% GC)
median time: 410.185 ms (0.00% GC)
mean time: 423.873 ms (0.00% GC)
maximum time: 480.239 ms (0.00% GC)
--------------
samples: 12
evals/sample: 1
# Flux#master
julia> @benchmark Flux.outputsize($m, (256, 256, 3, 50))
BenchmarkTools.Trial:
memory estimate: 278.48 KiB
allocs estimate: 6634
--------------
minimum time: 416.605 ms (0.00% GC)
median time: 417.849 ms (0.00% GC)
mean time: 419.333 ms (0.00% GC)
maximum time: 431.575 ms (0.00% GC)
--------------
samples: 12
evals/sample: 1
I think based on that, it's good to merge.
Think we still need someone with merge rights like @CarloLucibello |
Excellent, thanks for checking. I'm not super-sure how rights work, or whether merging is blocked to anyone not called Bors? |
bors r+ |
Yeah I had the same confusion. All I know is Github says I don't have merge rights, but I don't know if I'm allowed to call |
I now see "1 approving review by reviewers with write access", so Kyle's rights have been fixed and hopefully he should also be able to call bors. want to try calling bors yourself @mcabbott ? |
there you go |
Thanks Carlo! |
yeah merging is blocked also for me here, can go only through bors |
And my reading of ColPrac says that since Michael has write access only he is allowed to call |
yes, and this is enforced by current github's settings. Those settings are actually stricter than ColPrac since for colprac also an approval from someone without write access is enough |
OK, great. The direct merge button is still disabled for me, so I guess the enforcement is that Bors would not have listened to me, before the approval? |
that or it does its run then fails to merge, can't remember which one |
Build succeeded: |
If I'm reading the rules correctly, I may also merge PRs by other people, without another member's approval? Such as #1009, which just celebrated its first birthday... |
yes. approve then call bors |
Ok, I tried. It says I need to be made a reviewer? |
Closes #1466