jump-dev / JuMP.jl

Modeling language for Mathematical Optimization (linear, mixed-integer, conic, semidefinite, nonlinear)
http://jump.dev/JuMP.jl/
Other
2.17k stars 390 forks source link

Add _CONSTRAINT_LIMIT_FOR_PRINTING to control printing of many constraints #3686

Closed odow closed 3 months ago

odow commented 4 months ago

Closes #3651

We need to decide whether this is okay. It is conceivably breaking for people who rely on printing the model to a string, even if they really shouldn't be doing that.

One justification for doing this is that we added https://github.com/jump-dev/JuMP.jl/pull/3575 and I haven't heard any complaints, and it is pretty easy to suddenly spam a lot of content to stdout if your model is large.

codecov[bot] commented 4 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 98.33%. Comparing base (4be967c) to head (675c444).

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #3686 +/- ## ======================================= Coverage 98.33% 98.33% ======================================= Files 43 43 Lines 5696 5711 +15 ======================================= + Hits 5601 5616 +15 Misses 95 95 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

odow commented 4 months ago

An alternative might be to print at most N constraints of each function-set type. That would give a more representative print of the model.

blegat commented 3 months ago

I like MOI's _PrintOptions. I think we unify MOI and JuMP printing and we should start by having the same option struct.

odow commented 3 months ago

Developer call agrees that we could do something different in the longer term, but that this is sufficient for now. We can merge and then wait to see if anyone complains.

LebedevRI commented 1 month ago

It would be nice if these kind of knobs be mentioned in the docs, otherwise they are kind-of hard to find.

odow commented 1 month ago

We have purposefully chosen not to mention these in the docs. They are currently part of the internal API.

Is there an issue with the current defaults? Why do you want to change them?

LebedevRI commented 1 month ago

We have purposefully chosen not to mention these in the docs. They are currently part of the internal API.

Is there an issue with the current defaults? Why do you want to change them?

(I agree that the current default is better than nothing, as discussed.) I wanted to view some of the constraints that got omitted from the output.

odow commented 1 month ago

There are probably better tools for viewing a subset of constraints. For example, you could loop through all_constraints(model).