separate Sup3rGen and Sup3rGan

[malihass]

In prevision of the addition of the conditional moment models, make Sup3rGan inherit from Sup3rGen which is a model that contains only the generator details.

This way, the conditional moment model will be able to inherit from the Sup3rGen class and will not carry the extra attributes associated with the discriminator.

I am opening the PR now in order to avoid large branch divergence since this PR changes how we call the base model

[bnb32]

forgot to remove this

[bnb32]

Separating this is a good idea

[bnb32]

Im wondering if we should still call this file base.py, since it includes the "base" Gan model. This would avoid all the renamed imports, although that alone shouldn't prevent an improvement.

[malihass]

Yes, now that I think more about it, aside from the conditional moments models, all the models are GANs, so we can probably keep it as base

[grantbuster]

@malihass a few comments:

1. You might want to consider a forked inheritance hierarchy instead of a linear one. The Sup3rGan and Sup3rGen have different purposes and different model structures so having one be a subclass of the other may not be good OOP practice. For example, the majority of methods in Sup3rGan are just revising/overwriting the methods from Sup3rGen. You're basically writing two set's of methods for the two classes, a sign that maybe they should be parallel, not parent/child. The common methods should be abstracted into another parent class. This might not seem like a big deal, but one example where this kind of architecture causes problems down the road is because Sup3rGen has it's own purpose for the conditional moments so you might find yourself adding new methods specifically for that purpose, which would have to be removed or overwritten in the Sup3rGan.
2. You should use super().__init__ methods - the init's have lots of duplicated lines
3. If you add a new class that is meant to be instantiated and used directly (not abstract) you should add tests with that class.
4. Nitpicky - Sup3rGan and Sup3rGen look very similar, would be better to rename Sup3rGen to Sup3rGenerator or Sup3rRegression (I prefer the latter)

[malihass]

My plan was to make Sup3rCondMom inherit from Sup3rGen, but then having 2 instantiated class and one being not used may be misleading still, and also points towards having just Sup3rCondMom and Sup3rGan and make them being siblings rather than parent/offspring.
I'll open another PR where I rework that interface by adding another abstract class which grabs all the utilities we have for training in Sup3rGan and that Sup3rCondMom can inherit from. I won't add Sup3rCondMom or Sup3rGen for now.

[grantbuster]

My plan was to make Sup3rCondMom inherit from Sup3rGen, but then having 2 instantiated class and one being not used may be misleading still, and also points towards having just Sup3rCondMom and Sup3rGan and make them being siblings rather than parent/offspring. I'll open another PR where I rework that interface by adding another abstract class which grabs all the utilities we have for training in Sup3rGan and that Sup3rCondMom can inherit from. I won't add Sup3rCondMom or Sup3rGen for now.

Gotcha yeah agree with everything you just said. Here's one structure that I think might be most clean:

AbstractInterface (rename current AbstractSup3rGan) ->
AbstractSingleModel (has the non-overwritten common methods in Sup3rGan+Sup3rGen; "single" as opposed to the multi step models that use AbstractInterface) ->
Sup3rCondMom + Sup3rGan