Fixing backward propagation for vector vortex

[GillesOrban]

Fixes #186.

[codecov]

Codecov Report

Merging #193 (8ba5f4d) into master (2b707bc) will increase coverage by 0.33%.
The diff coverage is 80.00%.

@@            Coverage Diff             @@
##           master     #193      +/-   ##
==========================================
+ Coverage   81.47%   81.81%   +0.33%     
==========================================
  Files          97       97              
  Lines        7300     7304       +4     
==========================================
+ Hits         5948     5976      +28     
+ Misses       1352     1328      -24     

Impacted Files	Coverage Δ
hcipy/coronagraphy/vortex.py	94.55% <80.00%> (+12.23%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[ehpor]

Thanks for tackling this; much appreciated. The code is working as far as I can see. Thanks for adding the tests too. So only style changes remaining. A few general comments:

• Never directly compare floating point values. Due to numerical noise, the exact value of a float can vary. You should always use np.allclose(img.intensity, img.V). That compares the two values to within an absolute and relative tolerance. Also, I feel it's better to compare each value in the Field, rather than the sum of the values. I've marked these lines with "Never directly compare floating point values.". These are the direct cause for your failed tests.
• HCIPy uses tabs for indentation, sadly. That was an early choice that I should have made differently, but now we have to live with it until we can find a way to fix it without losing all git history. You're using spaces for indentation in the test files. These are the direct cause for most of the flake8 linting errors.
• There are a few more flake8 errors, all whitespace related. You can see them by going towards "Files changed" in this PR. The first 20 errors/warnings should be annotated inside the code, but there are more, most of which are similar to the ones that are annotated.
• I prefer a "rebase" instead of a "merge" when making this branch up-to-date with master. See https://github.blog/changelog/2022-02-03-more-ways-to-keep-your-pull-request-branch-up-to-date/#:~:text=Rebasing%20applies%20the%20changes%20from,and%20then%20click%20Rebase%20branch. It's a little cleaner than a merge.

[GillesOrban]

Thanks for the review, comments and guidelines. I was indeed a big confused by the tabs vs whitespace usage.
For the 'rebase' instead of 'merge', I am actually not sure how I can undo my merge in the pull request to instead do a rebase. I can revert my merge locally, do a rebase and push it, but not 100% sure this is equivalent and what you prefer (and the cleaner).

[ehpor]

@GillesOrban

Thanks for the review, comments and guidelines. I was indeed a big confused by the tabs vs whitespace usage. For the 'rebase' instead of 'merge', I am actually not sure how I can undo my merge in the pull request to instead do a rebase. I can revert my merge locally, do a rebase and push it, but not 100% sure this is equivalent and what you prefer (and the cleaner).

No need to try to undo. It's mostly for future PRs / future rebases.

[ehpor]

@GillesOrban Thanks for the latest flake8 fixes. I'll re-review this later today. FYI: you should also add your ulg.ac.be email to Github so that your commits are linked to it.

[ehpor]

Last comment; something that I missed during my first review.

I fully checked all the tests this time as well, and all seems good with those.

[ehpor]

All changes were addressed. LGTM.