Skip to content
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

DeepBiLSTM #201

Open
efosler opened this issue Aug 27, 2018 · 2 comments
Open

DeepBiLSTM #201

efosler opened this issue Aug 27, 2018 · 2 comments

Comments

@efosler
Copy link
Contributor

efosler commented Aug 27, 2018

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.

@ramonsanabria
Copy link

Hi Eric,

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?

Thanks!

@efosler
Copy link
Contributor Author

efosler commented Aug 27, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants