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

fit_loader vs. fit_generator #24

Closed
githubnemo opened this issue May 21, 2017 · 5 comments
Closed

fit_loader vs. fit_generator #24

githubnemo opened this issue May 21, 2017 · 5 comments

Comments

@githubnemo
Copy link

I feel that having a fit_loader is a special case of Keras' fit_generator and I found myself in a situation where I was missing the latter.

Is there a reason why fit_loader is not implemented as syntactic sugar for fit_generator and fit_generator is missing completely?

@ncullen93
Copy link
Member

fit_loader is the same thing as fit_generator... pytorch just calls them "loaders" while Keras calls them "generators". The Keras implementation of fit_generator iterates through the generator and calls train_on_batch. I'm actually working on a re-write so if you have any specific requests let me know.

@githubnemo
Copy link
Author

githubnemo commented May 22, 2017

I don't think that they are equal. Generators are a very generic concept in python. I can easily do a modification of an already existing loader using generators. But the reverse doesn't hold.

For example, I stumbled upon a problem with torchsample where I needed labels for a secondary loss that did not use any labels but torchsample forces me to use labels for every defined loss function, otherwise it is not executed. This would have been easy with generators:

def mnist_modified():
    for _, (data, target) in enumerate(mnist_train_loader):
        yield ([data,data], [target,target])

But with fit_loaders I would have to implement a whole loader instead.
Generators are the more generic approach. I agree that it is convenient to have fit_loader but it can be implemented with fit_generator and the latter should exist as it is the more generic of both methods.

At the chance of drifting off-topic, I like the fact that torchsample provides much functionality from Keras but I think it takes a lot of the flexibility when defining losses. I would have liked it if torchsample was a bit less convenient but a bit more flexible. I would be perfectly content with torchsample demanding that I supply several values in my training function (val_loss, loss, ...) as long as it lets me define the information flow of my data and the loss function. The compile and fit functions feel very static to me.

@Ajk4
Copy link

Ajk4 commented Oct 7, 2018

+1

In my use case I am creating [X,Y] batches on-the-fly from some in-memory objects. And I cannot generate all possible [X,Y] outcomes ahead of time because it would not fit in memory.

It seems like pytorch loaders are designed for fixed and fitting-in-memory datasets. Method fit_generator would be aplicable in my use-case where data_loaders are not enough.

@Ajk4
Copy link

Ajk4 commented Oct 7, 2018

@ncullen93 Would you be interested in merging PR if I would have code it?

@Ajk4
Copy link

Ajk4 commented Oct 8, 2018

@githubnemo I found another keras-like wrapper library that has fit_generator and that I can recommend -> https://pytoune.org/

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

3 participants