Conversation
| @@ -0,0 +1,2 @@ | |||
| * :func:`iris.util.array_equal` now has a 'withnans' keyword, which provides | |||
| a NaN-tolerant array comparison. | |||
There was a problem hiding this comment.
You've targetted this at the v2.2.x branch but included a whats new entry to the 2.3.0 whats new?
|
NOTE: This might call into question whether cube-comparison should also be made nan-tolerant ?? It's harder, as
I think it's also less likely to cause internal Iris errors, like this one So, I'm proposing that we ignore this problem for now. |
| @@ -1,4 +1,4 @@ | |||
| # (C) British Crown Copyright 2014 - 2015, Met Office | |||
| # (C) British Crown Copyright 2014 - 2019, Met Office | |||
There was a problem hiding this comment.
Did you want to follow your suggested approach and remove the year
There was a problem hiding this comment.
The template for the new file headers is here:
https://github.com/SciTools/scitools.org.uk/blob/master/documents/scitools_licensing.md#source-preamble
There was a problem hiding this comment.
I think I'd rather do it separately.
My reason is, I just realised, we are going to have to modify the licence-header check in test_coding_standards.py first ... see #3285
|
|
||
| * :func:`iris.util.array_equal` now has a 'withnans' keyword, which provides | ||
| a NaN-tolerant array comparison. | ||
|
|
There was a problem hiding this comment.
I'm torn with this.
Part of me wants it in under a sub-heading, similar to the "Bugs fixed in 1.7.3" sub headings in the 1.7 what's new but I'm not sure...
There was a problem hiding this comment.
Hmm. It's awkward because bugfix releases aren't supposed to contain new features !
We could treat the new keyword as a "private matter" for now, and then announce it with enormous fanfare in the nest minor release ??
I think that means putting the whatsnew contribution back into a textfile in a contributions_2.3.0 directory. The actual code changes (+docstring) can stay though,
Would you favour that solution @lbdreyer ?
There was a problem hiding this comment.
I believe the outcome of the offline discussion was to keep what you have already done.
Admittedly the reasons for that decision are a little fuzzy we discussed this over a week ago, but I think I personally wanted to not keep it private, but not add confusion by adding a "features added in 2.2.1" section
So basically, I'm happy with this change as it is.
|
@pp-mo It looks like this PR is ready to go! Do you mind rebasing to resolve the conflict and then it can be merged? |
|
Rebased ! |
|
I am going to restarted all the travis ci jobs now that #3311, which fixes the tests, is in. |
|
Tests all pass 🎉 |
* Allow coords with NaNs in to compare equal. * Tests for AuxCoord.__eq__ and util.array_equal(withnans=True). * Move whatsnew contributions into existing whatsnew document. * Better logic in util.array_equal.
* Allow coords with NaNs in to compare equal. * Tests for AuxCoord.__eq__ and util.array_equal(withnans=True). * Move whatsnew contributions into existing whatsnew document. * Better logic in util.array_equal.
* Allow coords with NaNs in to compare equal. * Tests for AuxCoord.__eq__ and util.array_equal(withnans=True). * Move whatsnew contributions into existing whatsnew document. * Better logic in util.array_equal.
Following the discovery #3282,
found that saving regridded cubes would fail because when a regridded dependency coordinate (orography in this case), coord contains NaNs, then "coord != coord".
Changes here implement a nan-tolerant comparison, so a coord containing NaNs does compare equal to an identical one (or itself).
Example of resulting save error :