-
Notifications
You must be signed in to change notification settings - Fork 336
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
Passing a float in repeat
as a dimension size prevents correct usage afterwards
#309
Comments
Hi @Maykeye Switching from plain LRU to typed LRU would solve this problem, but incurs a slow-down, so I'll just to accept current behavior and treat this situation as a programming error (i.e. user should fix it). As a recovery: |
repeat
fails if before it was used improperlyrepeat
as a dimension size prevents correct usage afterwards
The fix is that is appropriate for the user is changing
The fact it is named Maybe just add an assert in |
Consider the scenario
Working environment is jupyter notebook(that's where this bug affects code in the wild)
I call
repeat(image, 'h -> (h H)', H=H)
withH=2.0
(float, not integer). It fails complaining about types. OK, fair (in real code I usedheight/factor
where bothheight
andfactor
are integers, in this simplified scenario 2.0 will suffice)I call it again with
H=2
(int). It fails. What? But it fails if and only if I did step (1). If I don't, it works fine.I did some digging and saw that functions use LRU cache.
So working theory is if you call repeat improperly, you will taint the cache.
I call repeat enough of times with different arguments to cleanse LRU cache
I call it again with
H=2
(int). Everything works fine.Here's full code to reproduce.
The output is
If we are not hiding exception in
should_not_fail
, the full unexpected error isand if repeat is never called with float, only
is displayed
Einops 0.7.0.
Torch. 2.2.0+cu121
Python '3.11.7 (main, Jan 29 2024, 16:03:57) [GCC 13.2.1 20230801]'
ETA: yep, replacing in
_apply_recipe
a call to_reconstruct_from_shape
with_reconstruct_from_shape_uncached
gets rid of error. So the bug happens because hash(2.0) = hash(2)(Also
functools.lru_cache(1024, typed=True)
doesn't help as bandaid solution as from the lru_cache's PoV function always receives the same typeaxes_lengths: HashableAxesLengths
)The text was updated successfully, but these errors were encountered: