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

Feed entire input to encoder?? #17

Open
NeteeraAF opened this issue Jan 3, 2021 · 1 comment
Open

Feed entire input to encoder?? #17

NeteeraAF opened this issue Jan 3, 2021 · 1 comment

Comments

@NeteeraAF
Copy link

I see in your implementation that you feed entire signal into the encoder,
while the paper has noted that each timestemp should be insert seperatly.
When you feed the entire signal into the encoder, you get some overlapping features with the Conv kernel (except for the case that the stride equal to the kernel size).

Why did you implement like that? do you think it does not matter ?

Thanks!

@NeteeraAF NeteeraAF reopened this Jan 3, 2021
@altomanscott
Copy link

I have this doubt as well. I notice that in the paper the training inputs are segmented into small chunks with each chunk feeding into the encoder to the the feature representation z_t which will then feed into g_ar(GRU). The context C_t from the g_ar are then used to predict feature representation z_{t+k} from the future time frame. I don't know if I have the correct understanding of the paper or not.

In this implementation, I think the entire signal are fed into the encoder, the produced feature representation are split into two, the first part fed to the g_ar (GRU), then the g_ar learns to predict the second part of the representation features.

I believe that these two are different models and concepts which would bring different results. I really hope that the author could elaborate on point.

Thanks!

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