fix compare bug

[marqh]

this is a subtle bug

for certain configurations of python and numpy

calendars[0] == calendars

returns False, whilst

calendars == calendars[0]

returns array([ True, True,], dtype=bool)

therefore

np.all(calendars[0] == calendars)

returns False, whilst

np.all(calendars == calendars[0])

returns True

as type coercion, where it occurs, tends to happen left to right, this order is safer

[DPeterK]

type coercion, where it occurs

Maybe it would be better to avoid type coercion entirely?

[marqh]

i'm struggling to understand these test failures. These tests worked before and after the last change was proposed and merged

i can change the test results, but I'm not followiing why that should be required
the matplotlib versions are the same, i don't know what else could lead to this discrepancy

[coveralls]

Coverage remained the same at 90.566% when pulling e88bb1e on marqh:compare into d64de36 on SciTools:master.

[marqh]

@bjlittle please may you have a quick look and see if any clues about test changes jump out?

[tv3141]

@marqh To me it seems the matplotlib version actually did change.

The Travis logs in this pull request show that matplotlib 2.0.0 was used, while the Travis logs of the last successful run, pull request #19 use matplotlib 1.5.1.

Btw Travis did fail in the previous pull request #21, but it shows as succeeded in the pull request itself.

[marqh]

To me it seems the matplotlib version actually did change.

that would explain the test changes

thank you
@tv3141

[coveralls]

Coverage remained the same at 90.566% when pulling 580019b on marqh:compare into d64de36 on SciTools:master.

[coveralls]

Coverage remained the same at 90.566% when pulling 580019b on marqh:compare into d64de36 on SciTools:master.

[DPeterK]

@marqh please note that @lbdreyer and @bjlittle had not approved this PR. The fact that I had does not mean this PR was necessarily merge-ready.