add isapprox for arrays, with ≈ and ≉ synonyms

[stevengj]

As discussed in #12393, this adds an isapprox(x,y; rtol=sqrt(eps), atol=0, norm=vecnorm) function for arrays, analogous to isapprox for numbers. The definition is exactly the same except that abs is replaced by norm, and you can specify a norm via the norm keyword argument.

Rationale: this is the most natural extension of isapprox to arrays and shares the same definition, is a useful function for arrays (especially for test programs), and people often get it wrong (e.g. FactCheck.jl arguably got it wrong in their roughly function as discussed in #12393, which checks isapprox pointwise — this is almost always the wrong thing to do).

This PR also adds synonyms ≈ (U+2248, LaTeX \approx) and ≉ (U+2249, LaTeX \napprox) for isapprox and !isapprox, respectively. The official definitions of these symbols ("almost equal to") and the LaTeX abbreviations both mirror our isapprox function, so it is not really reasonable for people to define these to be any other function (and if you do need other notions of approximate equality there are other available Unicode operators, e.g. U+2245). And the binary operator is a lot more readable than isapprox (as long as you are satisfied with the default tolerances).

[stevengj]

As an added benefit, now if you do @test x ≈ y or @test x ≉ y, the @test macro treats it like any other comparison (because these parse as :comparison expressions) and prints the operands for test failures. This removes a lot of the need for @test_approx_eq, which I always found ugly.

And you can also chain isapprox comparisons with other comparisons, e.g. a ≤ x ≈ y ≤ b.

[tkelman]

CI is screwed up with build number collisions (appveyor/ci#353) and a mac freeze, can you rebase and force push this branch again?

[stevengj]

Thanks, @tkelman. I needed to update NEWS anyway.

[StefanKarpinski]

The thing that bothers me about this is that it seems very common to need to tweak the behavior of isapprox. As soon as you need to do that the nice ≈ syntax can't be used. At least now that we don't automatically import operators, you can define your own ≈ operator, but it seems to me that it might be better to make it easy to do that – i.e. write something like @approx reltol=r abstol=a which defines ≈ in the current scope with the given relative and absolute tolerances. If we could make isapprox smart enough that it's rare to need to tweak it, then just letting ≈ be an alias seems ok.

[stevengj]

@StefanKarpinski, if you look at our own test/ directory, it looks like > 90% of our @test_approx_eq calls use the default tolerance (as opposed specifying the tolerance via @test_approx_eq_eps). So, your claim seems empirically false to me.

[stevengj]

I also just grepped for all usages of isapprox in registered packages and, again, > 90% of the usages employ the default tolerances.

[StefanKarpinski]

Perhaps, but then why do we always seem to have random tests that fail because their tolerances are too tight? cc: @jiahao, @andreasnoack (who probably have the best sense of this)

[pao]

We (read: @stevengj) did just change the default tolerances to Better Values, so perhaps this is less of an issue now?

[StefanKarpinski]

I'd be thrilled be wrong about this, I just thought it worth bringing up as a concern.

[jiahao]

@StefanKarpinski's observation is closely related to #5605 - many of the linear algebra tests (and probably tests for other numeric features too) use very loose tolerances that are not theoretically rigorous, and so in many cases are severe overestimates but in some other cases may be underestimates.

[stevengj]

Rebased.

[StefanKarpinski]

Since you guys are the ones who actually use isapprox often, whatever you decide is fine by me – this certainly does look nicer.

[stevengj]

@jiahao, should I go ahead and merge once the tests are green?

[jiahao]

Sure

[stevengj]

(My feeling is that most @test_approx_eq tests employ the default tolerances because that they are checking for gross errors, not subtle roundoff sensitivities. If a test is accurate to half the significant digits, then analyzing the accuracy of the remaining digits involves a delicate error analysis that is often not available.)

[tkelman]

signature may need to be updated to match this in the RST docs

[stevengj]

Thanks, fixed.