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

Allowing target inputters to accept SequenceRecordInputter dtype #157

Open
veskoch opened this issue Jun 26, 2018 · 3 comments
Open

Allowing target inputters to accept SequenceRecordInputter dtype #157

veskoch opened this issue Jun 26, 2018 · 3 comments

Comments

@veskoch
Copy link
Contributor

veskoch commented Jun 26, 2018

Hi –

I am looking at the SequenceToSequence class. It requires the target inputter to be a of inputters.WordEmbedder while inputters.SequenceRecordInputter raises an exception. The source inputter can be of either type.

Are there any design/practical reasons necessitating the limitation?

What would be the best way if I want to add support for a inputters.SequenceRecordInputter target inputter in SequenceToSequence?

@veskoch veskoch changed the title Making target inputters accept SequenceRecordInputter types? Allowing target inputters to accept SequenceRecordInputter dtype Jun 26, 2018
@guillaumekln
Copy link
Contributor

Hello,

Could you describe the use case for this? Is the goal to produce vectors instead of symbols?

@veskoch
Copy link
Contributor Author

veskoch commented Jun 26, 2018

Hi

Thank for the fast reply. Yes, my goal is to produce vectors. I have encoded both the source input and the target output as one-hot vectors in a .tfrecord file.

@guillaumekln
Copy link
Contributor

It seems like most use case are equivalent to producing symbols, or can be emulated by symbols.

Additionally, some TensorFlow components we used for dynamic decoding assume that ids are produced (for example tf.contrib.seq2seq.BeamSearchDecoder).

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

No branches or pull requests

2 participants