sage.numerical.interactive_simplex_method: improve support for base fields other than QQ and RDF

[mkoeppe]

We remove the ad-hoc conversion of data to RDF in InteractiveLPProblem.feasible_set. This is outdated and problematic:

• the polyhedra code over RDF is not robust at all
• Sage has good support for algebraic polyhedra, in particular via normaliz.

We also make the printing code in _latex_product more robust:

• it no longer relies on SR to decide whether a coefficient needs to be wrapped in parens; instead, we use the same simple test that sage.misc.repr.coeff_repr already uses
• recognizing trivial coefficients (0, 1) is switched to comparing text instead of comparing elements - in order to support fields such as SR where == is magic

Rebased version of:

• interactive_simplex_method: Improve support for base fields other than QQ, RDF #31312

Author: @mkoeppe, @ComboProblem

Resolves #31312.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[github-actions]

Documentation preview for this PR (built with commit e5035be; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

[mkoeppe]

@ComboProblem I think this is an unintended change. Could you investigate what's causing this behavior?

[ComboProblem]

The issue is in Line 316-322. For the text input, with c=-1 and v = var("x"), we have that t.strip() = '-1' and c = 1. So the if block here isn't executed and the else block code writes a coefficient of c=1into the expression.

Furthermore, with fields that have a presentation of 1 that is not the string 1, we have that outputs are not as we'd expect for a coefficient of 1. See the attached example with RDF.

For the -1 as a coefficient example, I think a change to line 316 like if t.strip() == '1' or t.strip() == '-1': would fix this. For fields with different presentations of 1 other than the string 1, I'm unsure of how to approach this.

[mkoeppe]

I think we can live with 1.0 showing as 1.0; what's more surprising to me is that the objective constant shows as 0, not 0.0

[ComboProblem]

The default constructor for InteractiveLPProblem specifies the objective_constant_term term as the integer 0 rather than the base ring element 0. The code doesn't explicitly convert the objective_constant_term to an element of the base ring.

[mkoeppe]

Thanks. That should probably be changed.

[ComboProblem]

I've just opened a PR that fixes this with the other changes discussed so far.

[mkoeppe]

Thanks! I've merged your PR mkoeppe#41 now

[mkoeppe]

@ComboProblem I've copied in the ticket description from the old ticket #31312. Part of what it's promising:

• recognizing trivial coefficients (0, 1) is switched to comparing text instead of comparing elements - in order to support fields such as SR where == is magic

Could you add a test that uses an LP with coefficients from SR (for example, constant symbolic expressions such as pi or log(2) or sqrt(5))