Menu
▾
▴
#3463 Documentation: mention parameter epsilon_lp more explicitly in documentation for minimize_lp
The minimize_lp function depends on the parameter epsilon_lp which defaults to 1e-8. This has the effect that minimize_lp returns garbage for some problems which live in the numbe range of 0...1. E.g. doing l-infinity polynomial approximation of x^3 with a 6th degree polynomial in range 3/4 to 1 fails to find the solution x^3. If epsilon_lp is set to 0, this works as expected.
Since the default value is really rather large (but possibly appropriate for finance stuff), I would recommend to mention epsilon_lp directly in the documentation of mimimize_lp (not just in the see also section). Also it should be mentioned if it is appropriate to set this to 0 if the input is rational. Possibly the algorithm should detect rational input and use an epsilon_lp of 0 then.
See also the discussion with subject "Should minimize_lp (simplex LP algorithm) with rational coefficients be exact / optimal" on maxima-discuss.
In maxima-discuss (subject: Should minimize_lp (simplex LP algorithm) with rational coefficients be exact / optimal) Leo Butler suggested to check case by case if the numbers compared with epsilon_lp are rational numbers or floating point numbers. He also suggested to issue a warning instead of avoiding divisions by small floating point numbers. There are definitely cases where this would lead to better results, but I guess this test is in there because otherwise other cases would lead to issues.
In any case, if rationals are used, such tests should not be used, either be checking this on each individual comparison with epsilon_lp or by checking this upfront for the problem description as suggested in my original request.
While implementing a type-check for rational inputs, I noticed the simplex code has a couple additional bugs:
floatp_sx is used to type-check the coefficients of the input optimization problem, but constantp is a better choice;
with floating point coefficients and epsilon_lp sufficiently small, the minimize_lp algorithm can through a spurious error because the code uses subtraction to remove terms extracted from the constraints; subst is a better option that does not end with errors on such problems.
These will be fixed in the same commit to fix the original bug, so that Michael's tests pass cleanly.
If you have something I can test, please let me know.
Fixed in commit a3fe13. I have added an edited version of Micheal's tests to the testsuite.
See also commit d769c45.