Opened 3 years ago

Last modified 3 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: ↓ 2 Changed 3 years ago by

### comment:2 in reply to: ↑ 1 Changed 3 years ago by

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 3 years ago by

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 3 years ago by

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: ↓ 6 Changed 3 years ago by

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 3 years ago by

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: ↓ 8 Changed 3 years ago by

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 3 years ago by

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

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