That's not how I read it.
For each position t and offset Δ∈ such that t+Δ≤L, we form a pair (z_t,z_t+Δ).
For a given t, this produces up to m pairs:
(z_t,z_t+Δ_1),(z_t,z_t+Δ_2),….
We treat these as local neighborhoods at multiple scales. Note that the pairing is causal: we only pair t with positions strictly to its right (future), consistent with left-to-right language modeling.
So z_t is a token in the input, and z_t+Δ is some later token. Guess they could have flipped that around to (z_t-Δ, z_t) with t+Δ>=0.
> So z_t is a token in the input, and z_t+Δ is some later token.
I think you get what I'm saying, but when they compute the gate they do:
If I'm reading it right g_t = geometric_mix(z_t, z_(t+delta))Which would mean that g_t includes t+Δ, which is a future token. It's leaking future tokens into the current math.
So it could just be a sign error and still be right in the code, or I could just be getting it wrong.
If I'm not though, and given that they got worse results than a standard transformer I really hope it's fixed in the code. If they do worse even when knowing the future it's bad news for the idea.
Fair point. If only the paper had a link to the code.
I found this[1] repo which tries to reproduce it, and its accompanying blog post[2] uses (z_t, z_t - delta), without further mention.
Another repo[3] trying to reproduce it also does the reverse from what I can see, so (current, past).
Interestingly the first repo got underwhelming results, while the second repo matched the paper roughly. Not sure if it's related to the Claude-usage or not in the first, though it notes a lot of details were left out of the paper which is true.
[1]: https://github.com/Infatoshi/grassmann-flows/
[2]: https://github.com/Infatoshi/grassmann-flows/blob/main/blog....
[3]: https://github.com/kanenorman/grassmann