# How would I use Supposition.jl on computer arithmetic corner cases?

**URL:** <https://discourse.julialang.org/t/how-would-i-use-supposition-jl-on-computer-arithmetic-corner-cases/119418>\
**Category:** General Usage\
**Tags:** question\
**Created:** [September 15, 2024, 1:42am UTC](https://discourse.julialang.org/t/how-would-i-use-supposition-jl-on-computer-arithmetic-corner-cases/119418 "2024-09-15T01:42:14Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [September 15, 2024, 6:24am UTC](https://discourse.julialang.org/t/how-would-i-use-supposition-jl-on-computer-arithmetic-corner-cases/119418/6 "2024-09-15T06:24:08Z")

</div>

This is an interesting question, thank you for bringing it up! I think the most relevant section of the docs here is [Alignment of Documentation · Supposition.jl Documentation](https://seelengrab.github.io/Supposition.jl/stable/Examples/docalignment.html), since it talks about these kinds of issues a bit in the context of floating point values in particular. Documenting these kinds of behaviors is IMO the best course of action.

Unlike with the precision of `sincosd`, I don’t think there’s any guarantee about the precision of the basic `sincosd` relative to `cosd` and how it should behave when shifting the phase of the input by 90°. So whether this inexactness is considered “broken” or not is really not that easy to answer! What I would do is basically the same as what @jar1 suggested - use `isapprox` with an absolute tolerance and check that the output is always within that tolerance. For a single operation like `sind` on a `Float64`, this is typically [1 ULP](https://en.wikipedia.org/wiki/Unit_in_the_last_place), and the result is compared to `sind` on a `BigFloat`. For your example though, you’d still have to compare the `Float64` results of `sind` & `cosd` with `isapprox`.

Note also that it’s going to be _extremely_ difficult to guarantee a large number of trigonometric identities to hold, even within some chosen precision. See e.g. [this floating point favorite of mine](https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929) for an example where it’s hard.

* * *

All that being said - your intuition of using error plots as a guiding principle is spot on! In this example, I’d try to plot the error over the range you’re interested in and just take a look at how bad it really is. Since this is about trigonometry, I’d forego the `*d` versions and use `sin`/`cos` directly, producing a plot of all `Float16` numbers in [0, 1].

Maybe the overall error is already acceptable, maybe the worst case is MUCH worse than the example Supposition.jl found. Remember, it tries to find the minimal _input_ that produces the same test result, which may not necessarily be the minimal _error_ that you’re actually interested in! You could try to find that with `target!(abs(sind(x+90) - cosd(x)))` (see [this doc section](https://seelengrab.github.io/Supposition.jl/stable/Examples/target.html)), which looks like it could be simple enough to work out.

---

_[View the full topic](https://discourse.julialang.org/t/how-would-i-use-supposition-jl-on-computer-arithmetic-corner-cases/119418)._