Opened 4 years ago

Last modified 4 years ago

#20433 new enhancement

InteractiveLPBackend: Implement set_verbosity

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-7.2
Component: numerical Keywords: lp
Cc: novoselt Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

InteractiveLPBackend should somehow display the output from run_simplex_method as a side-effect when the backend's verbosity level is high enough.

Can I just print the HtmlFragment output from run_simplex_method? Will this work in all notebook interfaces?

Change History (8)

comment:1 follow-up: Changed 4 years ago by novoselt

No it should not and we had this discussion already!

Verbosity is more or less for debugging purposes and should be just plain text.

The point of run_simplex_method is to construct application of the simplex method and return the output in case you want to do something with it. For example, the output from the dictionary method is combined with extra stuff when you apply it to a problem. You could also combine solutions of many problems for some purposes. If you don't like the name - we can change it to something better. If you want just the final state without output, we can do that too, say just put it in final_dictionary methods. I'd rather not sprinkle if construct_output: ... in the code for the sake of readability.

And the code should NEVER make any assumptions/adjustments for behaviour in different interfaces, there is the output framework which allows creating new frontends without digging in the whole Sage library and tweaking things. Displaying side effects are quite unpleasant to deal with for frontend maintainers (well, at least for me).

comment:2 in reply to: ↑ 1 Changed 4 years ago by mkoeppe

Replying to novoselt:

No it should not and we had this discussion already!

Note that this ticket is about the MIP backend, not the InteractiveLP code itself.

comment:3 Changed 4 years ago by novoselt

Good point, although in that case the output should probably be close to what other methods show and I still would expect only text output. Printing HTMLFragment will show you raw HTML code, I think, which is hardly useful.

comment:4 Changed 4 years ago by mkoeppe

Right. I guess I'll wait with this wishlist-item ticket until a need for verbosity arises in some problem where the code doesn't seem to finish...

comment:5 follow-up: Changed 4 years ago by novoselt

In that case you actually want things to be printed on every step, not in an assembled form. I would be also curious what can possibly go wrong as long as you stay with exact rings - theory suggests that simplex method will terminate sooner or later ;-) With inexact rings everything can go wrong in this backend and that's more of a feature.

comment:6 in reply to: ↑ 5 Changed 4 years ago by mkoeppe

Replying to novoselt:

In that case you actually want things to be printed on every step, not in an assembled form.

Yes.

I would be also curious what can possibly go wrong as long as you stay with exact rings - theory suggests that simplex method will terminate sooner or later ;-)

Well, it could be cycling, unless your code implements a non-cycling pivot rule (I didn't look).

It could actually be a nice exercise to implement the lexicographic simplex method by allowing the right-hand-side values to come from an ordered module over the base ring.

With inexact rings everything can go wrong in this backend and that's more of a feature.

Probably the code should signal an error or warning when a problem is set up with an inexact field...

comment:7 follow-up: Changed 4 years ago by novoselt

It uses Bland's rule, so no cycles should happen.

I don't see a point in warnings (and especially errors) for inexact field, otherwise we should start with warnings about stuff like

sage: one_third = RR(1/3)
sage: one_third
0.333333333333333
sage: 1 - one_third - one_third - one_third
1.11022302462516e-16
KeyboardInterrupt
sage: - one_third - one_third + 1 - one_third
5.55111512312578e-17
sage: - one_third - one_third - one_third + 1
0.000000000000000

In teaching I found it quite natural to use my module with RealField(20) to get usually sensible results in sensible representations for word problems. When bad things do happen, it is a great point to illustrate that blindly trusting computers is not a good idea and using simplex method in practice is a bit more complicated than it sounds ;-)

comment:8 in reply to: ↑ 7 Changed 4 years ago by mkoeppe

Replying to novoselt:

It uses Bland's rule, so no cycles should happen.

The pivot rule used would probably be worth mentioning in the documentation.

I don't see a point in warnings (and especially errors) for inexact field, otherwise we should start with warnings about stuff like

sage: one_third = RR(1/3)
sage: one_third
0.333333333333333
sage: 1 - one_third - one_third - one_third
1.11022302462516e-16
KeyboardInterrupt
sage: - one_third - one_third + 1 - one_third
5.55111512312578e-17
sage: - one_third - one_third - one_third + 1
0.000000000000000

In teaching I found it quite natural to use my module with RealField(20) to get usually sensible results in sensible representations for word problems. When bad things do happen, it is a great point to illustrate that blindly trusting computers is not a good idea and using simplex method in practice is a bit more complicated than it sounds ;-)

I think there's a difference between basic arithmetic and a packaged algorithm implementation. One usually one would expect that an implementation that accepts floating point numbers has some kind of accommodation for floating point fuzz in the form of some epsilon.

But, in any case, just a suggestion.

Note: See TracTickets for help on using tickets.