WIP: Add more unit tests for modeling#1060
Conversation
There was a problem hiding this comment.
@nden Is this a bug or am I using MatrixRotation incorrectly?
In [1]: from astropy.models.rotations import MatrixRotation2D
In [2]: m = MatrixRotation2D(angle=42)
ERROR: AssertionError: Expected angle to be a number [astropy.models.rotations]
---------------------------------------------------------------------------
AssertionError Traceback (most recent call last)
<ipython-input-2-77a226a12d7e> in <module>()
----> 1 m = MatrixRotation2D(angle=42)
/Users/deil/Library/Python/2.7/lib/python/site-packages/astropy-0.3.dev3922-py2.7-macosx-10.8-x86_64.egg/astropy/models/rotations.pyc in __init__(self, rotmat, angle)
173 outdim=1, paramdim=1)
174 else:
--> 175 self._validate_angle(angle)
176 self._angle = Parameter('angle', np.deg2rad(angle), self, 1)
177 super(MatrixRotation2D, self).__init__(parnames=[], ndim=1,
/Users/deil/Library/Python/2.7/lib/python/site-packages/astropy-0.3.dev3922-py2.7-macosx-10.8-x86_64.egg/astropy/models/rotations.pyc in _validate_angle(self, angle)
199 a = np.asarray(angle)
200 assert isinstance(a, numbers.Number), \
--> 201 "Expected angle to be a number"
202 assert a.ndim == 0, \
203 "Expected angle to be a number"
AssertionError: Expected angle to be a number
|
I wanted to cover the CYP, CEA, CAR, MER and COP projections in the tests and to avoid code duplication parameterized @nden Do you have a suggestion how I should change the test to cover those projections? |
|
@nden Can you add a simple example that shows the purpose of Note to self: Remaining things not covered by tests in
(I really don't get the purpose of |
There was a problem hiding this comment.
This gives an error on Python 2.6: https://travis-ci.org/astropy/astropy/jobs/7057516#L1286
Does anyone know how to do this correctly?
(If not I'll simply remove that assert statement, it's not very important.)
There was a problem hiding this comment.
Instead of exc.value try exc[1].
|
@cdeil I don't think the cylindrical projections can be tested this way. The reason is that the cylindrical projections need parameters which are saved in the PV keywords and Actually looking at wcs more carefully now, there might be a way to read and set the PV keywords but I can't get it to work. @mdboom Should this work: The header has "PV" keywords but I am getting an empty list. Should I get a list of those? Further more if I do I get the same result as when I have not set the pv values. |
|
@mdboom I think there was a problem with the data file. I can confirm now that |
There was a problem hiding this comment.
@nden @iguananaut What do you think? Should I assert the current string format here or remove the TODO?
There was a problem hiding this comment.
The current is fine if you want to put in a test for this. Any changes I've proposed to the existing format are not special and can easily be changed. In fact if I did change the format there was no particular deliberate reason to do so. Maybe I just did whatever was useful to me for testing.
|
@nden @iguananaut Maybe we can merge this PR soon and then we do separate issues / PRs for the remaining tasks mentioned here? I can work on this tomorrow a bit though, so if there's anything you'd like me to add / change / fix in this PR, let me know. |
|
@cdeil I've been working on a generalized WCS and the projections were implemented for that purpose. It is not clear to me whether we will use the current wcs in the future but even if we do my understanding is it is going to handle FITS WCS only. In any case the projections were a good test for the framework and I don't see a reason to remove them. I've adapted your tests to work with the maps in There's also a separate branch with minor fixes to the projections module and I ran the tests against it. For this I am going to make a pull request but not until I look at @iguananaut 's changes. |
Fix projections Addresses some of the questions in #1060.
Address problems with constraints reported in #1060 and #1064 There's still a minor issue with constraints which is that after fitting the constraint attributes on the parameter objects are reset to the default values. But the model.constraints object has the correct values. I am going to merge this so it can be used and will open a different issue for this last problem I am aware of. It doesn't affect fitting but can be misleading.
|
@cdeil Are you still planning to do more with this? If not, do you think you could rebase it against master so that I can merge it? These tests will be helpful in continuing to work on testing new ideas for the API. |
|
Or is the issue that some of the TODOs need addressing by people other than @cdeil ? |
|
@cdeil Are you waiting for me to do something? Can this be merged? |
|
looks like it needs to be rebased now... |
|
Sorry I started this big PR and then didn't have time to finish it. A lot has changed in |
|
👍 A lot of these tests would still be very useful to have. At one point I was delaying further work on #1086 until this was merged :) |
|
What's relevant in this PR was moved to #1548. Closing this. |
I will add more unit tests for modelling in the coming weeks.
constraints.pycore.pyfitting.pyfunctional_models.pyparameters.pypolynomial.pyprojections.pyrotations.pyutils.pyFurther suggestions welcome.
To find the un-tested parts of
modelingI use this command to generate the coverage report locally:python setup.py test --coverageThere's also a nightly generated coverage report on the web:
https://jenkins.shiningpanda.com/astropy/job/astropy-coverage/coveragepy/?