flowersteam / explauto

An autonomous exploration library
http://flowersteam.github.io/explauto
GNU General Public License v3.0
64 stars 27 forks source link

Put forward and inverse models in explauto/models ? #63

Closed sebastien-forestier closed 8 years ago

sebastien-forestier commented 8 years ago

Should we put explauto/sensorimotor_model/forward and inverse in explauto/models ? Pro: models should be in /models Con: forward and inverse models are only used in sensorimotor_model

@pierre-rouanet @clement-moulin-frier

clement-moulin-frier commented 8 years ago

Hi Sébastien,

The original idea was rather to have the algorithms in /models (in particular if they used elsewhere that in sensorimotor_model, i.e for the interest models) and the interfaces (i.e. subclasses of SensorimotorModel) in /sensorimotor_models. This is for example what was done for the IMLE model.

I'm actually not really aware of the fact that we now have two separate subdirectories, forward and inverse. It seems a bit strange to me since most models can be used both in a forward and in an inverse way. Do you know what was the reason of this split?

sebastien-forestier commented 8 years ago

The forward/inverse split comes from the adapted import of the useful part of Fabien's code, that was previously hidden in "third_party". This allow in particular to easily combine any forward model with any inverse model algorithm (e.g. LWLR-BFGS, LWLR-CMAES). Currently only NN and WNN appear in both, but the algorithms for those forward and inverse models are not the same, specially for WNN. IMLE and ILO-GMM, are directly in /sensorimotor_models as they compute both forward and inverse models.

clement-moulin-frier commented 8 years ago

OK. So to reply to your previous question:

I would put in explauto/models the code that can potentially be used in different packages (i.e. not only in sensoriotor_model).

Or more practically speaking: I would address this issue only at the time when it becomes problematic for whatever reason. Is it the case now?

sebastien-forestier commented 8 years ago

Ok. No problematic reasons, it was just to know what is the best way. So yes let's keep that as I think nothing will be used elsewhere. The only code that is used also in interest_model is the dataset.py so I already put it in /models.