Fix definitions of == and isless

[devmotion]

Given the definitions of == and isequal in ForwardDiff#master, the PR reverts 337539f (see #10) and defines both ==(x, y) and isequal(x, y) in terms of both value(x) and epsilon(x) etc. This makes

• the definitions in ForwardDiff and DualNumbers consistent,
• the definitions of == and isequal in DualNumbers consistent,
• the definitions of == and isequal mathematically correct.

Additionally, the PR fixes isless: According to its docstring, isless(x, y) should

Test whether `x` is less than `y`, according to a fixed total order (defined together with `isequal`). `isless` is not defined for pairs `(x, y)` of all types. However, if it is defined, it is expected to satisfy the following:
- If `isless(x, y)` is defined, then so is `isless(y, x)` and `isequal(x, y)`, and exactly one of those three yields true.
- The relation defined by `isless` is transitive, i.e., `isless(x, y)` && `isless(y, z)` implies `isless(x, z)`.

On the master branch, however, the first requirement is not satisfied (e.g., choose x = dual(3, 0.5) and y = dual(3, 1.0): then neither isless(x, y), isless(y, x), nor isequal(x, y) is satisfied).

cc @andreasnoack who was involved in #10

[codecov]

Codecov Report

Attention: Patch coverage is 83.33333% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 51.88%. Comparing base (d9251a7) to head (d52f6a3).

Files	Patch %	Lines
src/dual.jl	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #103      +/-   ##
==========================================
+ Coverage   50.94%   51.88%   +0.94%     
==========================================
  Files           2        2              
  Lines         212      212              
==========================================
+ Hits          108      110       +2     
+ Misses        104      102       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[devmotion]

@mcabbott I think you might be interested in this change.

[mcabbott]

This looks right to me, at first glance.

I see that #104 recently adopted the other convention.

But I have never used this package and am unsure who does, or the value of maintaining it in parallel to ForwardDiff.

[dlfivefifty]

This package predates ForwardDiff.jl and its value is mostly in its simplicity and accessibility.

The "right" thing to do is move ForwardDiff.Dual here. But that would require someone to take the initiative, and some functionality would need to be added to ForwardDiff.Dual to maintain feature parity.