Fix unit tests errors with numpy >=1.13 (Fix 577)

[cpascual]

This PR fixes the 4 test errors/failiures reported in #577 and adds new travis builds with numpy 1.14

3 of the 4 problems are relatively trivial to solve.

The remaining one (test_isreal) is not so trivial because it involves allowing to compare a non-dimensionless quantity against zero. The reason is that numpy.isreal(x) essentially does x.imag !=0 if the imag method is implemented in x... and since Quantity reimplements .imag to return units (see #171), the check always returns False if x is a non-dimensionless quantity.

As mentioned, this can be solved by allowing comparisons against zero. Actually, this has already been requested in #194, but it was not implemented.

In this PR, I implemented the comparison-to-zero feature and provide several new unit tests for it. AFAIK this implementation takes into account the concerns expressed by @hgrecco in #194. But if the feature is not wanted, we can just revert the last 3 commits of this PR and then test_isreal will left with an expected failure flag.

The rules that I implemented for the comparison-with-zero are:

    a) comparing against (non-quantity) zero is allowed for any quantity
    b) comparing against zero-magnitude quantities of incompatible
    dimensionality raises a Dimensionality error, except for the case
    of equality, for which it always returns False
    
    Notes:
    1.- Numpy arrays of zeros are also supported and the comparison rules
    apply elementwise
    2.- In the case of non-multiplicative units, the rules above
    apply after converting to base units if the autoconvert offset flag
    is set. Otherwise they raise an OffsetUnitCalculusError.

Fixes #577

[cpascual]

Hi @hgrecco , as we talked in #614, I would be happy of practising the bors workflow with this PR.
But I do not think that I should merge my own PR until someone else (you or someone else with commit rights) gives me a green light. So, would you have a look or appoint someone else to do it?

[cpascual]

bors try

[bors]

🔒 Permission denied

Existing reviewers: click here to make cpascual a reviewer

[cpascual]

bors try

It seems that @hgrecco should give me permissions in bors beforeI can try... I got this email:

:lock: Permission denied

Existing reviewers: [click here to make cpascual a reviewer](https://app.bors.tech/repositories/2346/add-reviewer/cpascual)

[hgrecco]

Great work. Go ahead and try to merge it (I could do it but I want to try again the Bors workflow, I have given you access).

[cpascual]

bors try

[bors]

try

Build succeeded

• continuous-integration/travis-ci/push

[cpascual]

I attempted to do a bors try and the outcome is kind of confusing to me: a new travis test appeared which is failing due to what it looks like a bors/github configuration problem (fatal: Remote branch trying.tmp not found in upstream origin).

So now I am going to attempt the bors r+ directly

[cpascual]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push

[cpascual]

Since this was an experiment on usin bors, here are some observations:

• even if bors r+ succeeded, I see that each invocation triggers 2 builds in travis, one on the staging.tmp branch and another on the staging branch. Of these, the first systematically fails with what looks like a config problem. But the actual result of the command seems to be affected only by the result of the second.

• a similar thing happens with the bors try command

In the bors docs it says:

Your CI system should build the “staging” and “trying” branches, but should not build a branch called “staging.tmp”

I think that this can be fixed by adding the following blacklist to travis.yml (I submitted PR #631 to test it)

branches:
  except:
  - staging.tmp
  - trying.tmp