Hey @ascillitoe , I have formed the function around the method you provided, this is the notebook:
Thanks a lot for the explanation about the topic.
Nice work! I just noticed I should have probably taken the absolute values of the coefficients when sorting to find the largest ones (as we want largest values not the most positive), so the plots=... line becomes plots = (-np.abs(coeffs)).argsort()[:nplot]. After that, it would be great if you could add this into a PR!
We like to keep all the plotting functions in plot.py, so you could define a plot_regpath() method there. This could then be called by a wrapper function elastic_net().plot_regpath() defined in solver.py (i.e. a method belonging to the elastic_net solver class). So the final use case would be:
mypoly = eq.Poly(parameters=myparam, basis=mybasis, method='elastic-net',
sampling_args={'mesh':'user-defined',
'sample-points':X, 'sample-outputs':y})
mypoly.solver.plot_regpath()
Oh, okay I will make the changes and add it to the solver file
Hey @ascillitoe , I was working on creating the wrapper function, I had a doubt that if we add this in the solver.py , what parameters will we be taking as input because I think we would need to change the implementation of the function a little, because defining the function in solver.py raises an error that elastic_net object has no attribute solver.
The elastic_net subclass is actually stored as an attribute of the Poly class (when method='elastic-net'), so Poly.solver() will return an elastic_net object in this case. i.e. we wouldn’t expect the solver itself (elastic_net) to have a solver attribute.
If you can share your code in a branch on your fork I can take a look?
Sure, I will provide the link ASAP
Hey @ascillitoe , sorry for the late reply,
This is the link the github file containing the code(line 1006):
What I am thinking that instead of defining the function in solver.py, shouldn’t we define it in Poly.py
Since this plot_regpath method is specifc to the elastic_net subclass only, I think it makes more sense to keep it as an attribute of that class. Otherwise we’d have to add code in poly.py to deal with occasions when the user calls Poly.plot_regpath() despite having selected a different solver such as method='least-squares'.
It looks like the issue is just that you are referencing the Polynomial within plot_regpath() in solver,py, but in solver.py we call plot_regpath(self), i.e. we’re passing in the elastic_net solver object. Hopefully a fix will be to change lines 288 and 304-309 in solver.py to:
def plot_regpath(Solver,nplot=None,save=False,show=True,return_figure=False):
"""
...
"""
lamdas = Solver.lambdas
x_path = Solver.xpath
IC = Solver.ic
IC_std = Solver.ic_std
idx = Solver.opt_idx
elements = Polynomial.basis.elements
The elements = ... bit is a little tricky, as this requires Polynomial.basis.elements which aren’t stored within the elastic_net solver. I have an idea for this, but for now I reckon its best to remove the elements bit, and for the labels simply do label = 'j = %d' %j i.e. just label the coefficients by the column number for now.
I was thinking that in Poly.py we are already using loops to check the solver used, hence we can call the method there, also in this we can call the basis.elements too.
I will try this method and send the code asap.
Hey @ascillitoe , I tried running the code but it is still showing an error, I also tried giving super().method as a parameter for the function in solver.py but its still not working.
Its tricky for me to see what’s going on without looking at the entire codebase. I’ve just created a new branch called feature_plotting. Would you be able to commit what you’ve done and do a PR to this new branch please? Then I can take a look and try running it.
By the way, I think feature_plotting is one commit ahead of you. I’m hoping there will be no conflicts but let me know if you have any issues merging.
Yeah sure, I will upload my files on the repository
I will check the code and update you, thanks
This is the colab notebook for the current method: