Skip to content

Conversation

OlivierHnt
Copy link
Member

🥳

@OlivierHnt
Copy link
Member Author

I think I figured out a way to resolve the issue with two arguments @interval T x vs @interval x y .

The rest of the modifications are just polishing. Let's merge this ASAP if you both agree @lbenet and @Kolaru.

@lbenet
Copy link
Member

lbenet commented Sep 17, 2025

Can you give me a couple of days to check if Taylor-related packages are ok with these changes? Would there be a v0.23.1, or shall we jump directly to v1.0?

@OlivierHnt
Copy link
Member Author

Of course! 🙂
A priori I would prefer go directly to v1.0 instead of 0.23.1, unless a bug, or some serious adjustment(s) need(s) to be done of course.

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Sep 18, 2025

I think we should add exact as a constructor of ExactReal (to do things like exact(im) or exact(::AbstractArray) etc.)

Actually, one thought occurred to me: since ExactReal <: Real, should we only define exact as a constructor and disallow ExactReal?
It seems possible that the conversion / promotion system can end up wrapping a Real as an ExactReal "implicitly".

If this is indeed a reasonable concern, then I suggest we replace the ExactReal constructors with exact as a conservative measure for the 1.0 release. Non breaking changes (even restoring ExactReal as a constructor) can always be made later on.

@Kolaru
Copy link
Member

Kolaru commented Sep 18, 2025

It seems possible that the conversion / promotion system can end up wrapping a Real as an ExactReal "implicitly".

That's a good catch, it is in fact possible.

julia> a = ExactReal[]
ExactReal[]

julia> push!(a, 1)
1-element Vector{ExactReal}:
 ExactReal{Int64}(1)

Thanksfully that Intervals behave correctly in this case:

julia> b = Interval[]
Interval[]

julia> push!(b, 1)
1-element Vector{Interval}:
 [1.0, 1.0]_com_NG

So yes, disabling the direct ExactReal constructor is a good idea.

I think that the implementation of the @interval macro (which I only partly understand for now) is not quite correct:

julia> @interval exp(3) exp(10)
┌ Warning: invalid interval, NaI is returned
└ @ IntervalArithmetic ~/.julia/dev/IntervalArithmetic/src/intervals/construction.jl:437
┌ Warning: interval part of NaI
└ @ IntervalArithmetic ~/.julia/dev/IntervalArithmetic/src/intervals/construction.jl:273
┌ Warning: invalid interval, NaI is returned
└ @ IntervalArithmetic ~/.julia/dev/IntervalArithmetic/src/intervals/construction.jl:437
∅_ill

julia> @interval Float64 exp(3) exp(10)
[20.0855, 22026.5]_com

I'm not sure what is going wrong in the first case.

What did you do to mul! for the LinearAlgebra extension? Is it just a change in the matmul configuration?

Other than that, everything looks fine to me, I especially like the new fround function :)

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Sep 18, 2025

What did you do to mul! for the LinearAlgebra extension? Is it just a change in the matmul configuration?

Yes, I re-added the functions default_numtype(), default_flavor(), etc. so that IntervalArithmetic.configure only redefines these functions.

That's a good catch, it is in fact possible.

Ok I have a commit, ready. I will push it now then.

@interval exp(3) exp(10)

Ah shoot. I'll try to give it an other try 😓

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Sep 18, 2025

I think @interval should be good now.
So the way it works is that the macro @interval a b calls x = _atomic(DEFAULT_TYPE, a) and y = _atomic(a, b), and return the interval interval(x, y).
We have two cases:

  • If a is a type T, then x == T, and y == atomic(T, b) (so classic behaviour)

  • If a is some expression, then x == atomic(DEFAULT_NUMTYPE, a) and _atomic(a, b) == hull(atomic(DEFAULT_NUMTYPE, a), atomic(DEFAULT_NUMTYPE, b); dec = :auto). So we compute twice the same intervals in this case, but that's fine in my opinion

For example:

julia> @macroexpand @interval exp(3) exp(10)
:(IntervalArithmetic.interval(exp(IntervalArithmetic._atomic(Float64, 3)), exp(IntervalArithmetic._atomic(exp(3), 10))))

So this may not be very sharp in general. Here, exp(IntervalArithmetic._atomic(exp(3), 10)) is ok since exp is monotone.
Anyways, maybe we can improve this later if needed?

@OlivierHnt
Copy link
Member Author

OlivierHnt commented Sep 18, 2025

Mhmm nightly is failing

LLVM ERROR: out of memory
Allocation failed

[2543] signal 6 (-6): Aborted [...]

It's probably nothing since the tests pass on 1.10, 1.11 🤷‍♂️

@Kolaru
Copy link
Member

Kolaru commented Sep 19, 2025

I agree that @interval can be improved later, if needed.

Therefore, everything now looks good to me, and this PR can be merged whenever @lbenet greenlights it (but no later than the 2nd of October, so it is released for my JuliaCon talk :D)

@lbenet
Copy link
Member

lbenet commented Sep 19, 2025

I agree that @interval can be improved later, if needed.

Fully agree with both of you!

Therefore, everything now looks good to me, and this PR can be merged whenever @lbenet greenlights it (but no later than the 2nd of October, so it is released for my JuliaCon talk :D)

So far, my checks on the Taylor-related packages are, ok. So green lights on my side too. I propose to release IA v1.0, then tag a new version of IntervalRootFinding (so it works with IA v1.0), and I'll release patches on TaylorSeries and TaylorModels; the latter requires the new version of IntervalRootFinding...

Congrats to all!

@lbenet
Copy link
Member

lbenet commented Sep 19, 2025

I just restarted the tests of the failed jobs (nightly)....

@codecov-commenter
Copy link

codecov-commenter commented Sep 20, 2025

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

Codecov Report

❌ Patch coverage is 72.82051% with 53 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.89%. Comparing base (1ace2a0) to head (5772366).
⚠️ Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
src/IntervalArithmetic.jl 60.60% 13 Missing ⚠️
...rc/intervals/interval_operations/set_operations.jl 72.72% 12 Missing ⚠️
src/intervals/construction.jl 40.00% 9 Missing ⚠️
src/intervals/rounding.jl 76.92% 9 Missing ⚠️
src/intervals/exact_literals.jl 33.33% 8 Missing ⚠️
ext/IntervalArithmeticLinearAlgebraExt.jl 90.90% 2 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #728      +/-   ##
==========================================
- Coverage   78.27%   77.89%   -0.39%     
==========================================
  Files          31       31              
  Lines        2923     2922       -1     
==========================================
- Hits         2288     2276      -12     
- Misses        635      646      +11     

☔ 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 Sep 20, 2025

Tests are passing with the next release candidate 1.12.
So I think we are fine.

@OlivierHnt OlivierHnt merged commit 544c000 into JuliaIntervals:master Sep 20, 2025
16 of 21 checks passed
@OlivierHnt OlivierHnt deleted the release-1.0 branch September 20, 2025 05:20
@mforets
Copy link
Contributor

mforets commented Sep 25, 2025

congratulations for the release, thanks for the hard work 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants