n3fit should use existing code for pdfbases

[Zaharid]

We have

https://github.com/NNPDF/nnpdf/blob/master/validphys2/src/validphys/pdfbases.py

which is done in a declarative way and is integrated well with vp. We should use that in n3fir rather than reinventing the wheel, so that one can have fits with any basis defined there.

[scarlehoff]

It's not clear to me whether this is referring to fitting, to convoluting with the fktables or just to the final output of the .exportgrid files.

[Zaharid]

• I guess I mean all of those. For FK we should do something like this

#404 (comment)

• n3fit/io/writer.py is completely redundant, and the kind of thing that we emphatically don't want to be rewriting zillions of time (and that I am a bit puzzled why it was rewritten...).

• n3fit/layers/Preprocessing.py should be trading basis objects rather than having various parameters that you have to get right simultaneously.

[scarlehoff]

* n3fit/io/writer.py  is completely redundant, and the kind of thing that we emphatically don't want to be rewriting zillions of time (and that I am a bit puzzled why it was rewritten...).

The code was not born using vp. It is a very mundane reason.
I realise that a lot in writer.py is redundant that's why I've spend very little time on it. The same thing should be true for reader.py although I have the feeling this second one will stay for a long time.

* n3fit/layers/Preprocessing.py should be trading basis objects rather than having various parameters that you have to get right simultaneously.

I guess you refer rather to Rotation.py? if so yeah, I agree. I think it would be a good first-issue/low-hanging-fruit for someone wanted to make themselves familiar with the code.

You can also do it to Preprocessing.py of course, but that is not just trading a basis, is changing how to fit the preprocessing (or if you do it at all) which can be a more full-fledged project.