Code is in drp_stella tickets/PIPE2D-109.
Tests are in drp_stella/tests/Math.py, part of the tests in Utils.cc as I couldn't figure out how to pass PolyFit keywords and keyword values from Python to C++. To test use master obs_pfs and master drp_stella_data and run

python tests/Math.py

• Please clean up history. If possible, remove commits which are unrelated to this ticket (all the cleanups) and put them on another ticket.
• Please set mask bits to indicate where clipping has taken place.

Moved all clean-up commits to PIPE2D-114 and set mask bits where clipping has taken place.

I added a bunch of comments on this PR. However, I screwed up, and some of the comments seem to have appeared in odd places. I hope that everything is clear enough, but do ask if anything isn't or if something seems to be missing.

One thing that I found rather odd is the structure of the PolyFit tests. I see you referred to these above, but I didn't notice that until after I'd looked at the code. I think it would be worth spending a bit more effort to figure out how things are supposed to work.

I hope that after you've acted on my comments the code will be rather easier to read, and, at that point, I'd like to take another look through before we merge.

I believe I addressed all comments from the previous review.

This is a significant improvement over the previous version of the code: thank you! Particularly welcome are the improved commit messages — it's much easier to understand what you've actually done.

Some more comments on the PR. Most of these are quite minor, though; while I encourage you to read them, I think you can ignore most of them. Here are things I'd specifically like you to act on:

• If I understand correctly, you always perform sigma clipping, even if the user specifies nIterReject=0. That seems like pretty pathological behaviour. At a minimum, I think you need to make this clear in the documentation for the nIterReject option and print out a big warning when the users asks for no iterations but you give them one anyway.
• Take out the if True in testPolyFit.
• Squash 4962901 into 43f0228.
• Expand the commit message of 43f0228 to explain why this change was necessary.
• 40b75e0b should clearly be squashed into something: it's not a well-formed commit on its own.
• Based on the commit messages, f9aa3554 seems to be addressing the same issue as 077f70ad7. Please clarify what's going on here — if these commits really are degenerate, remove one (or squash them); if not, change the messages so they can't be confused.
• 12ed6b53 seems to be entirely superseded by 1778b3b2. Remove it.
• I don't understand the motivation for 2c01217. If the measurement errors aren't used, why are you initializing them or allocating space for them at all? I don't see why one set of useless numbers is "cleaner" than another set of useless numbers.
• c0726b254 is entirely degenerate with 03b9440ae. Remove it.
• There are several separate commits which initialize various arrays or variables to 0. I don't understand why these have suddenly become necessary: are they fixing bugs (if so, where are the tests?) or are you just being neat? Can we at least squash all these various commits into one?
• 1778b3b2 definitely requires a unit test. I'm worried that the tests added in 9cf52a3 didn't catch this problem — why not?
• The changes in 09058d0 are very very extensive. I suggest:
  • Rather than making this change last in the history of the ticket, you add the relevant headers so you can use logging as the first commit. Then never add any #ifdef __DEBUG... statements at all during this work: all of the output you are adding on this ticket can be a call to the logger, and you will not need this final commit to convert them all.
  • File another ticket to convert any output which was not added on this ticket to use the logger.

I'd like to take another look at this before we regard it as finally done, so I'm setting it back to "in progress" for now.

• I changed the PolyFit function with sigma rejection to not perform the sigma rejection at all if nIterReject=0.
• I don't see an if True in testPolyFit...?
• Regarding 2c01217 I now only create a ndarray of length 1, added comments to the code, and changed the commit message
• Regarding the initializing commits, the change in 03b9440 regarding sigma and covar is purely cosmetical, while the change in ee5215c (removed 2 initializations as they were unnecessary) was a bug fix (test added)
• Regarding 1778b3b2 there are tests in the source code. The issue itself is very difficult to test from outside the function.
• I applied all other suggested changes, except for the last one as it was too late for that, but will keep it in mind next time...

• I think 188710084 is new since I looked at this previously. If these are purely cleanups, it seems like they'd be better suited on PIPE2D-114.
• Similar story for f050bcd9c: you should not add new trailing spaces in any commit — where that's happened on this ticket, you need to edit the commit to take them out again. You should not insert them on one commit and then add another to take them out again. A commit to go through old work and remove spaces that were incorrectly added on other tickets is pure cleanup, and belongs on PIPE2D-114.
• Here is the if True I object to: https://github.com/Subaru-PFS/drp_stella/blob/f3ed39943d32bcbfaf0f128d290fb979281fa7b9/tests/Spectra.py#L517
• Please file a ticket to request that testPolyFit() in Utils.cc (ie, the C++ code, not the Python) should be split into multiple separate functions.
• Please file another ticket to request that the C++ test code be replaced with (or augmented by) Python tests when either we figure out how to wrap the necessary functionality with Swig or we replace it with pybind11.

Otherwise, go ahead and merge.

Fixed commits by removing freshly introduced trailing spaces.
Moved clean-up commits to PIPE2D-114.
Added tickets PIPE2D-157 and PIPE2D-158.

Merged into master