Repository navigation
Cannot define constraint more than once #219
Description
I think the new implementation with Symbolics is broken because constraint can only be called once. This breaks interactive usage.
Here is the example from the README:
julia> using IntervalConstraintProgramming, Symbolics
julia> vars = @variables x, y;
julia> constraint(x^2 + 2y^2 ≥ 1, vars) # first call works
Separator(in(-1 + x^2 + 2(y^2), [0.0, ∞)_dac), vars=x, y)Then calling constraint another time (note that you need to stop the previous run, e.g., separate commands in the REPL):
julia> constraint(x^2 + 2y^2 ≥ 1, vars)
ERROR: ArgumentError: `==` is purposely not supported when the intervals are overlapping. See instead `isequal_interval`I do not fully understand why it works the first time. It seems that some other code path is taken. I guess the reason must be that some methods are only defined later and an old definition is taken during the first run.
Simplified version
Here is an even more simplified version:
using IntervalConstraintProgramming, Symbolics, IntervalArithmetic
julia> vars = @variables x, y;
julia> ex = -1 + x^2 + 2y^2;
julia> c = interval(0, Inf);
julia> ex in c # first call works
in(-1 + x^2 + 2(y^2), [0.0, ∞)_dac)julia> ex in c
ERROR: ArgumentError: `==` is purposely not supported when the intervals are overlapping. See instead `isequal_interval`Environment
(IntervalConstraintProgramming) pkg> st
Project IntervalConstraintProgramming v0.14.0
Status `~/.julia/dev/IntervalConstraintProgramming/Project.toml`
⌅ [d1acc4aa] IntervalArithmetic v0.22.36
[43d83c95] IntervalBoxes v0.2.3 `~/.julia/dev/IntervalBoxes`
[15111844] IntervalContractors v0.5.0
[527681c1] ReversePropagation v0.3.0
[90137ffa] StaticArrays v1.9.15
⌅ [0c5d862f] Symbolics v6.58.0
Activity
dpsanders commentedon Dec 14, 2025
Ouch, that's bad... Thanks for reporting!
It's been a while since I looked at this and I don't immediately have any idea what the problem is...
dpsanders commentedon Dec 14, 2025
This looks (at first glance) like a bad interaction of Symbolics and IntervalArithmetic, rather than something innate to this package. Definitely needs to be fixed or worked around, though!
schillic commentedon Dec 14, 2025
My blind guess is that this is a world-age thingy. This package defines methods on-the-fly if I understand correctly, and my hunch is that, in the first call, these methods are not yet available and some other default methods (which happen to do the correct thing) are used.
schillic commentedon Apr 4, 2026
This was fixed in #221.