Circular Dependency issues

[ptiede]

On the new releases it looks like #710 is creating a large number of circular dependency issues on 1.10.

Here is a MWE in a fresh environment

Info Packages marked with ⌃ and ⌅ have new versions available. Those with ⌃ may be upgradable, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
┌ Warning: Circular dependency detected.
│ Precompilation will be skipped for dependencies in this cycle:
│  ┌ IntervalArithmetic → IntervalArithmeticRandomExt
│  └─ IntervalArithmetic → IntervalArithmeticLinearAlgebraExt
│ Precompilation will also be skipped for the following, which depend on the above cycle:
│   IntervalArithmetic → IntervalArithmeticSparseArraysExt
│   ExactPredicates
│   DelaunayTriangulation
│   IntervalArithmetic → IntervalArithmeticIntervalSetsExt
│   Makie
└ @ Pkg.API.Precompilation ~/.julia/juliaup/julia-1.10.9+0.x64.linux.gnu/share/julia/stdlib/v1.10/Pkg/src/precompilation.jl:583

I believe this is related to JuliaObjects/Accessors.jl#192 and is discussed in some detail JuliaLang/julia#52511. A temporary solution is to revert #710, which is what Accessors did as well.

[oameye]

Also hitting this

[OlivierHnt]

Thanks for reporting this issue.
What a shame. Is there a way to make a weak dependency depend on Julia version? (Here v1.11 and above)

[oameye]

I don't think it is possible

[OlivierHnt]

So if we don't have more than two standard libraries as package extension it is fine, right?
If so, for the 0.22.x releases, let us add Random as a dependency and define rand(::Interval) directly inside the IntervalArithmetic module.

Please correct me if I'm mistaken, but I believe that, in the long term, the Julia devs intend for the standard libraries to be treated like any other packages in the ecosystem.
Therefore, for the upcoming 1.0 release (cf. #698), we might consider restricting support to Julia version 1.11 and above.

[ptiede]

I wouldn't remove 1.10 support for a while. It is the LTS release and IntervalArithmetic is used by some pretty large packages so not getting bug fixes would be a shame.

[Kolaru]

I think that we can remove the Random extension altogether.

We had this discussion in triage at some point and concluded that rand(x::Interval) should not be kept for several reasons:

• rand(x::Real) is not defined, so following our strategy of "pointwise extension of real functions" there is no reason to have it. For the default julia operation we chose to not consider intervals as set (see the behavior of e.g. in or union).
• Sampling the interval uniformly is arbitrary. There is an argument to be made that we could have an extension for Distributions and make Uniform(x::Interval) valid, but I think it is niche.
• The behavior can be achieved using rand() * diam(x) + inf(x).

All that being said, I see no problem having a different name function to do this (just like we have in_interval and hull for set operations).

[OlivierHnt]

Yea that sounds reasonable. Do you have name ideas? randpick, draw, sample?

[lbenet]

I think that we can remove the Random extension altogether.

I fully agree; let's avoid headaches!

* The behavior can be achieved using `rand() * diam(x) + inf(x)`.

All that being said, I see no problem having a different name function to do this (just like we have in_interval and hull for set operations).

My point in #709 was that such a function (say sample, as suggested in dcf1ae7) should be inside IntervalArithmetic. It is extremely useful for TaylorModel's, and surely in other situations.