Skip to content

Release 1.0 #698

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft

Conversation

OlivierHnt
Copy link
Member

@OlivierHnt OlivierHnt commented Feb 21, 2025

This PR aims to prepare the 1.0 release.

@dpsanders
Copy link
Member

Very nice, thanks!

Whats the reason for removing @interval T a b?

@OlivierHnt
Copy link
Member Author

SparseArrays seems to have a hook _iszero and _isnotzero to handle missing; we may be able to use this as well for intervals.

@OlivierHnt
Copy link
Member Author

Whats the reason for removing @interval T a b?

Well that's just for consistency, since the method @interval a b is missing (I do not know how to implement it without conflicting with @interval T a)

@OlivierHnt
Copy link
Member Author

Aqua tests are failing on Julia 1.10 due to method ambiguities with mul!.

@OlivierHnt
Copy link
Member Author

I have removed the old functions which controlled the default behaviour for the flavor, matrix multiplication, the rounding, the power.
Now this is controlled by a configure(; rounding=:correct, flavor = :set_based, power = :fast, matmul = :fast) function.

@codecov-commenter
Copy link

codecov-commenter commented Mar 2, 2025

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 67.34694% with 16 lines in your changes missing coverage. Please review.

Project coverage is 77.58%. Comparing base (9f76820) to head (dae18ca).
Report is 26 commits behind head on master.

Files with missing lines Patch % Lines
src/intervals/real_interface.jl 51.72% 14 Missing ⚠️
ext/IntervalArithmeticForwardDiffExt.jl 33.33% 2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #698      +/-   ##
==========================================
- Coverage   78.04%   77.58%   -0.47%     
==========================================
  Files          30       30              
  Lines        2920     2913       -7     
==========================================
- Hits         2279     2260      -19     
- Misses        641      653      +12     

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Mar 2, 2025

Note: maybe interval(1, 2) == interval(3, 4) can safely return false since there is no overlapping numbers (this means that == can only return true if the two intervals are identical singletons). Whatever is decided should also be applied to isapprox.

@lbenet
Copy link
Member

lbenet commented Mar 2, 2025

The problem I see with the discussion around ==, <, >, iszero, etc, is that we are ending up defining methods by value, not by type; obviously, this touches type stability. The return type of these operators, if allowed, will be a Union{Bool, SomeError}, and while errors may be good and appreciated in certain cases, they also break the flow which may or may not be desired.

I think we could have them but within a submodule (e.g., Symbols). Then, we encourage the usage of isequal_interval, or if the submodule is loaded for these extensions, the user is concient of the subtleties, e.g. the returned union types. This proposal is to mimic the current usage of IntervalArithmetic.Symbols.

@Kolaru
Copy link
Collaborator

Kolaru commented Mar 3, 2025

I think a reasonable philosophy for v1.0 is

  • Interval act as much as a number as possible while keeping a guarantee of correctness. Which means that for them, we need to allow things like < and ==, but error when the operation is ill-defined as the pointwise extension of the function on number (e.g. (1..10) < (2..7) must be both true and false, and thus should error).
  • BareInterval do not extend any properties of numbers. They are pure intervals, do not interface with numbers and, notably, do not support the pointwise extension of boolean functions.

It could be nice to have some in-between for specific applications. But I think it is reasonable for the time being to redirect users to use BareInterval if the extended functionalities are a concern.

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Mar 14, 2025

Other things to do:

  • check this PR against IntervalRootFinding.jl @Kolaru
  • move det, eigvals, norm into a package extension

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Mar 17, 2025

I have added the following definition in the ForwardDiff extension:

ForwardDiff.DiffRules._abs_deriv(x::Dual{T,<:Interval}) where {T} =
    Dual{T}(ForwardDiff.DiffRules._abs_deriv(value(x)), zero(partials(x)))

We now get the behaviour:

julia> using IntervalArithmetic, ForwardDiff

julia> g(x) = abs(x)^2
g (generic function with 1 method)

julia> a = ForwardDiff.hessian(v -> g(v[1]), [interval(0)])
1×1 Matrix{Interval{Float64}}:
 [0.0, 0.0]_trv_NG

julia> b = ForwardDiff.hessian(v -> g(v[1]), [interval(-1, 1)])
1×1 Matrix{Interval{Float64}}:
 [-2.0, 2.0]_trv_NG

julia> c = ForwardDiff.hessian(v -> g(v[1]), [interval(1)])
1×1 Matrix{Interval{Float64}}:
 [2.0, 2.0]_com_NG

julia> d = ForwardDiff.hessian(v -> g(v[1]), [interval(-1)])
1×1 Matrix{Interval{Float64}}:
 [2.0, 2.0]_com_NG

(it used to error before)

Obviously, the correct answer is $2$, and c and d are consistent.

So a may be pretty bad; b is not ideal, but at least it contains the correct value $2$.
In both cases we have the trv decoration which indicates that the interval carries no meaningful information.

@Kolaru any thoughts? Could this break IntervalRootFinding.jl?
cc @agerlach

EDIT: now the derivative of abs at 0 returns $[-1, 1]$, see #703.

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Apr 27, 2025

On this version of the 1.0 release, ==, < are defined and other functions such as in and issubset work.
Whenever we have non-thin intervals that are overlapping when calling == and <, an error is thrown.

julia> x = interval(1); y = interval(2); z = interval(2, 3)
[2.0, 3.0]_com

julia> x == y
false

julia> y == z
ERROR: ArgumentError: `==` is purposely not supported when the number is contained in the interval. See instead `isthin`

julia> z == z
ERROR: ArgumentError: `==` is purposely not supported when the intervals are overlapping. See instead `isequal_interval`

julia> x < y
true

julia> y < y
false

julia> z < z
ERROR: ArgumentError: `<` is purposely not supported when the intervals are overlapping. See instead `strictprecedes`

julia> y in z
ERROR: ArgumentError: `==` is purposely not supported when the number is contained in the interval. See instead `isthin`

julia> z in z
ERROR: ArgumentError: `==` is purposely not supported when the intervals are overlapping. See instead `isequal_interval`

julia> issubset(y, z)
ERROR: ArgumentError: `==` is purposely not supported when the number is contained in the interval. See instead `isthin`

julia> issubset(z, z)
ERROR: ArgumentError: `==` is purposely not supported when the intervals are overlapping. See instead `isequal_interval`
julia> interval(2)  interval(2)
true

@OlivierHnt OlivierHnt linked an issue Apr 27, 2025 that may be closed by this pull request
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants