Use inf, sup (or bounds) instead of .lo and .hi

[lbenet]

No description provided.

[codecov-commenter]

Codecov Report

Merging #531 (b19f757) into 1.0-dev (49f4806) will increase coverage by 0.03%.
The diff coverage is 93.00%.

@@             Coverage Diff             @@
##           1.0-dev     #531      +/-   ##
===========================================
+ Coverage    85.40%   85.44%   +0.03%     
===========================================
  Files           34       34              
  Lines         1782     1814      +32     
===========================================
+ Hits          1522     1550      +28     
- Misses         260      264       +4     

Impacted Files	Coverage Δ
src/decorations/intervals.jl	83.33% <0.00%> (ø)
src/intervals/interval_operations/extended_div.jl	100.00% <ø> (ø)
src/plot_recipes/plot_recipes.jl	0.00% <0.00%> (ø)
src/decorations/functions.jl	81.76% <80.00%> (ø)
src/display.jl	82.91% <91.66%> (+0.33%)	⬆️
src/intervals/interval_operations/numeric.jl	97.61% <91.66%> (ø)
src/intervals/arithmetic/basic.jl	91.52% <91.83%> (ø)
src/intervals/arithmetic/trigonometric.jl	96.75% <97.27%> (+0.18%)	⬆️
src/intervals/arithmetic/power.jl	97.10% <97.43%> (ø)
src/bisect.jl	55.55% <100.00%> (ø)
... and 14 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 49f4806...b19f757. Read the comment docs.

[lbenet]

There are few instances left; by some reason, using inf/sup produces errors in the tests. So for the time being, I think this is ok...

[lucaferranti]

in general LGTM.

If I understand correctly the missing cases are

1. in trigonometric.jl, @round(F, half_pi(F).lo, atan(ylo, xlo)) we cannot use inf inside the round macro (at least without adding inf(a, RoundingMode) but feels too pedantic

2. bounds(x) = x.lo, sup(x) the reason for this (which is I guess also the reason for always normalising -0.0 to 0.0 when constructing the interval instead of directly "correctly" normalising lower and upper bound. Is that having -0.0 around leads some ambiguities errors in atan(y, x) computation (returns π instead of -π or viceversa). Given that the current thing works and given how idiotic the whole -0.0 vs 0.0 issue is in the first place, I would say this is fine, since it works

3. A couple of instances in the examples folder, but given those are probably outdated anyway I guess it doesn't matter

[Kolaru]

1. in trigonometric.jl, @round(F, half_pi(F).lo, atan(ylo, xlo)) we cannot use inf inside the round macro (at least without adding inf(a, RoundingMode) but feels too pedantic

F(inf(half_pi(F)), atan(ylo, xlo, RoundUp)) should do the trick (I don't want to mess with the PR while you are rebasing :))

[lbenet]

The last commit takes into account @Kolaru suggestions here.

[lbenet]

(Forgot to push the last commit...)

[lucaferranti]

@lbenet I suggest we merge this and leave the pi vs -pi nuisance for a separate PR

[lucaferranti]

also because since #533 is built on top on this and hence it also incorporates all the inf, sup changes, which makes review a little harder

[lbenet]

I think the last commit includes the nuisances related to pi you mean.

I agree: let's merge this, and afterwards I'll rebase #533 to 1.0-dev