How would one implement a Supposition.jl test for something like the following MWE? @check function phased(x = Data.Floats()) cosd(x) == sind(x + 90) end which fails due to floating point stuff x = 1.8014398509481896e16 (cosd(x), sind(x + 90)) which returns two different numbers. Just like ho…

You might check out isapprox and use that instead of == for floating-point comparisons.

I forgot to say that it actually fails isapprox as well. @check function phased(x = Data.Floats()) isapprox(cosd(x), sind(x + 90)) end Found counterexample Context: phased Arguments: x::Float64 = 1.8014398509481896e16 My original post before editing had isapprox in it because I tested…

So, more useful would be error plots I suppose. Though from the context of, I’m a package developer, I have implemented some math functions, and I’d like to verify them, so I’ll use Supposition.jl as the closest thing to formal verification that we have, and implement them as part of my tests. In t…

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 , since it talks about these kinds of issues a bit in the context of floating point values in particular. Documenting these ki…

Speaking hypothetically here, suppose there exists a package, let’s call it ComputationalErrors.jl (or maybe even just include the following in Supposition.jl). It has a macro, say @uncertainty. Analogous to @btime which outputs a measure of performance, @uncertainty would output a measure of uncert…

It’s not a bad idea, but I don’t think it’s a good fit for Supposition.jl. You can probably achieve this exact thing by using IntervalArithmetic.jl and checking that the true upper & lower bounds returned are within your margin of error, without having to add anything to Supposition.jl.

I think in this case, you might want to either restrict the domain or check for relative precision with respect to x. @check function phased(x = Data.Floats()) if !isfinite(x) || !isfinite(x + 90) return true end isapprox(cosd(x), sind(x + 90); atol=eps(x)/2) end Here, eps(x)/…

Oh it didn’t cross my mind to use a Taylor expansion in defining a tolerance, that’s a good idea. Would work well with autodiff utilities as well. And I guess that would make sense if I wanted a more flexible tolerance system for my property tests. But I’m thinking of the scenario: I pick up Julia …

I was going to suggest implementing something like that by hand (I wasn’t aware of this package), but I was unsure how to handle non-monotonic functions.

@mleseach are you talking about the Taylor expansion method for deciding a tolerance? I would guess that the Taylor expansion would be centered at the value the test is running on, so it should work for non-monotonic functions. What I would understand it wouldn’t work on is functions that are not C…

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

General Usage

jar1 September 19, 2024, 5:15am 19

Relevant discussion in History of `isapprox` in languages - #26 by Richard_Fateman and following.

Topic		Replies	Views
[ANN] Supposition.jl Package Announcements package , announcement , testing , fuzzing , property-based	20	2422	May 14, 2024
Approximate equality General Usage question , bug	54	35350	September 29, 2022
History of `isapprox` in languages Numerics question , numerics , approx	57	1926	September 19, 2024
Floating-point accuracy visualization example: the ULP error for each math function coming with Julia Numerics error , visualization , numerics , approximation , accuracy	20	719	February 6, 2026
Base.runtests("math") failures on chips older than haswell New to Julia	12	764	August 7, 2021

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

Related topics