#12533: arbitrary precision LP solver backend
-------------------------------------------+--------------------------------
Reporter: dimpase | Owner: ncohen
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-5.0
Component: linear programming | Resolution:
Keywords: arbitrary precision, LP | Work issues:
Report Upstream: N/A | Reviewers: David Coudert
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------------------+--------------------------------
Changes (by ncohen):
* status: needs_review => needs_work
Comment:
Helloooooooo Risan !!!
I just went over your patch, and some comments follow. Thank you very much
for the work you put into that ! `:-)`
**ppl.pyx**
* MIP_Problem : PPL can only solve continuous Linear Programs, can't it
? In this case why "MIP_*", unless it means something different from
"Mixed Integer Program" ?
* MIP_Problem.optimization_mode() prints something but does not return
anything
* MIP_Problem returns dictionaries : in MixedIntegerLinearProgram we
raise an exception for unbounded/infeasible problems, and return the
objective's value otherwise. Just mentionning it in case you may like it,
of course that's totally up to you ! I still think it wou * ld be easier
to return, for instance, a string (unbounded/infeasible) when the problem
has no solution, and the result otherwise.
* optimal_value does not only return the objective value, it also
solves the problem ! I think the docstring should be updated --> if the
users calls this function several times, are the computations made over
and over ?
* optimization_mode and set_optimization_mode : we often do both in a
unique function, i.e. a method with optional arguments such that
optimization_mode() returns the mode and optimization_mode(-1) defines it
as a minimization problem. I just noticed that it was not the case at all
for MixedIntegerLinearProgram methods, but I think we ought to change that
:-)
* is_satisfiable : does it also solve the problem ? I mean, if users
type "if p.is_satisfiable(): a = p.optimal_value()" does it solve it twice
? The docstrings should say something about that.
* what is the difference between optimal_value and
evaluate_objective_function ? In particular the code seems to be pretty
similar, so one function should probably call the other if two are
necessary
* OK : by looking at the docstring I have no idea what it does or what
the invariants are, but of course it may also be that I am not part of the
intended audience for this class
**sage/libs/ppl_ files**
* Are these files part of the ppl spkg ? If so they should not be
modified by a patch, and the spkg itself should be updated.. That's really
a lot of work for nothing, but that's how things are done here until we
change it `:-/`
**mip.pyx**
* Why would you have to add anything to get_values and solve ? The
flags you add would create problems instantly if the backend solver is not
PPL !! I think nothing needs to be changed in that file --> if the backend
is ppl then the values returned will be exact, otherwise they will just be
the usual ones. But I do not see why these functions should be changed
`O_o`
**ppl_backend.pyx**
* All functions should be documented/tested, even 'cutsom ones' like
``print_data``. Actually ``sage -coverage <filename>`` should never have
to complain `:-)`
* same thing with init_mip
* add_variable[s] say that the variable are positive by default. Are
they indeed ?
* "set_variable_type" -- I think the best is for this method's code to
be something like "raise Exception('This backend does not handle integer
variables ! Read the doc !')"
* why do you keep "exact" in the names of your get_values functions ?
It would be easier to name then get_values, as anyway all the values given
by the ppl interface are exact ?!
**Others**
* Is ppl.pyx part of the documentation ? At least ppl_backend is not,
so you should add it to doc/en/reference/numerical.rst
* Some "advertisement" should be added to the doc. In many places the
solvers are listed (ok, perhaps we should only list them at *one* place),
so that users can find out that *exact* answer are returned when the
solver is ppl
* Variables : are they automatically strictly positive ? This is the
default in the MIP class (because it is the default of the API we
interface), and if PPL acts any differently this would mean that results
would be different according to whether PPL or GLPK is used as a backend !
* The patch *does not apply* on 5.0-rc1, so I can not even check
whether tests pass !
Thank you again `:-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12533#comment:24>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
