Closed weinman closed 2 years ago
Thanks for noting this issue. You are correct that there is a mismatch between how the time constants are described in the paper and this repository, due to different versions of the paper. Since we are not training the time constants, this does not affect the overall results. However it does change the interpretation of the parameters.
Thanks. I see that 61aca54 fixes the dynamics to match the paper here. Thanks for that! The factorization is much cleaner/clearer (and maybe it's just me, but it also seems to run a bit faster).
I do still wonder a bit about the initialization/definition of tau_m
(and tau_s
) here.
self.tau_m = torch.nn.Parameter(1. / (1 - self.alpha), requires_grad=False)
Is this expression simply a convenient, log-avoiding approximation for
,
or is there something deeper I'm missing?
My thanks again for sharing this work.
The first order approximation is a relic of a previous implementation. The definition with the log you propose is perfectly valid and preferable.
Thanks to everyone involved for sharing the detailed code and well-written paper about the method.
I apologize if this is elementary, but I'm trying to reconcile the implementation of the dynamics in
class LIFLayer
with the equations written in the paper.Specifically, the
forward
method (here) updatesQ
andP
using memberstau_s
andtau_m
, respectively.These members are set in the constructor; for example (abridged for clarity)
Then
P
is updated asSince the paper defines (Equation 4)
and
I'm wondering why the line above isn't
(and perhaps also
tau_m = - dt / log(alpha)
, though I'm not sure this would matter as much sincetau_m
seems to have no other use in this class, yet it does inclass LIFLayerVariableTau
).Is it simply because
for the range of α values in use?
In sum, what is the reason for using
tau_m
andtau_s
for updatingP
andQ
respectively, rather than(1-alpha)
and(1-beta)
?