InteractiveLPBackend: Implement set_verbosity

[mkoeppe]

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?

CC: @novoselt

Component: numerical

Issue created by migration from https://trac.sagemath.org/ticket/20433

[novoselt]

comment:1

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).

[mkoeppe]

comment:2

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.

[novoselt]

comment:3

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.

[mkoeppe]

comment:4

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...

[novoselt]

comment:5

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.

[mkoeppe]

comment:6

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...

[novoselt]

comment:7

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 ;-)

[mkoeppe]

comment:8

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.