Closed LebedevRI closed 7 months ago
We don't recommend print(model)
for large models. But perhaps we should figure out a way to truncate the output.
We don't have any plans to improve the output, like detecting sets and printing stylized models. At one point (many years ago) JuMP used to do that, but it proved too complicated and fragile to maintain.
We'd have to decide if truncating printing by default is breaking though.
I'm imagining something like:
function _print_model(io::IO, model::AbstractModel; force::Bool)
N = num_variables(model)
if N > 100 && !force
@warn(
"There a $N variables in the model. Printing may produce an " *
"undesirably large amount of output. To force printing, use " *
"`print(model; force = true)`"
)
return
end
Right, lossily truncating the output is of course not always wanted. I understand that this issue is rather a nitpick.
I'm imagining something like:
This should also count number of constraints perhaps.
Here are some related issues where we have discussed this previously https://github.com/jump-dev/JuMP.jl/issues/3574, https://github.com/jump-dev/JuMP.jl/issues/2171, https://github.com/jump-dev/JuMP.jl/issues/795
I think the issue is that there is no one-size-fits-all approach to what people want from print(model)
.
What did you want or expect to happen in the original case?
I suppose i knew it would be printed the way it did, but i suppose i would've expected it to be printed in more succinct, non-unrolled, form.
I suppose i should look more into https://jump.dev/MathOptInterface.jl/stable/reference/standard_form/
Consider something as simple as
This produces ~30k lines of output.
Given that each
x[i]
can even have it's own type, i can't imagine solving this is too simple, but surely this can be improved?(I've encountered this the hard way, with chrome tab crashing (and, you can't even increase per-tab memory limits nowadays!), and had to fix it by manually going into
.ipynb
notebook...)