You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a reason that DeepBiLSTM has two variants (relu and non-relu)? I was thinking about creating a UniLSTM, and realized that all that really needed to happen were some flags being flipped. It seems like having one model file, DeepLSTM, would be better and have the activations and directionality be options to that model. The diffs between relu and non-relu seem minor.
For backwards compatibility, we could have model_factory just call the new function with the options set appropriately.
The text was updated successfully, but these errors were encountered:
Yes, "relu and non-relu" is something that I was trying long time ago. I think it was not very important.
Yes correct. This was the idea of model_factory to decouple models and IO infrastructure. We can even model this further and have a layer_factory (?). This was another idea that I had in my head long time ago. What do you think?
Should I bother trying to put the two back together? It would not be hard but if it's not on the critical path then I'm not going to bother. It shouldn't take more than 20 minutes to do.
I think I see what you mean, but just to clarify: how do you separate the models from the layers?
Is there a reason that DeepBiLSTM has two variants (relu and non-relu)? I was thinking about creating a UniLSTM, and realized that all that really needed to happen were some flags being flipped. It seems like having one model file, DeepLSTM, would be better and have the activations and directionality be options to that model. The diffs between relu and non-relu seem minor.
For backwards compatibility, we could have model_factory just call the new function with the options set appropriately.
The text was updated successfully, but these errors were encountered: