#18732: Add tableau query functions glp_eval_tab_row, glp_eval_tab_col to GLPK
backend
-------------------------------------+-------------------------------------
Reporter: mkoeppe | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.8
Component: numerical | Resolution:
Keywords: LP, glpk | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/yzh/add_tableau_query_functions_glp_eval_tab_row__glp_eval_tab_col_to_glpk_backend|
1cf22a926b785affdf53e33ea30c539850ae406a
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by mkoeppe):
Replying to [comment:9 ncohen]:
> {{{
> + cdef int * c_indices = <int*> sage_malloc((n+1)*sizeof(int))
> + if c_indices == NULL:
> + raise MemoryError("failed to allocate %s bytes" %
((n+1)*sizeof(int)))
> + cdef double * c_values = <double*>
sage_malloc((n+1)*sizeof(double))
> + if c_values == NULL:
> + sage_free(c_indices)
> + raise MemoryError("failed to allocate %s bytes" %
((n+1)*sizeof(double)))
> }}}
>
> can be replaced by
>
> {{{
> + cdef int * c_indices = <int*> sage_malloc((n+1)*sizeof(int))
> + cdef double * c_values = <double*>
sage_malloc((n+1)*sizeof(double))
> + if c_indices == NULL or c_values == NULL:
> + raise MemoryError
> }}}
>
> This occurs twice.
Nathann, if the second allocation fails, your version would leak the
memory of the first allocation.
> {{{for 0 < j <= i:}}} is "old-style", you should use "for j in range(i)"
instead, which is translated into the very same C code.
>
> Finally, this piece of code had bad side-effects:
>
> {{{
> + try:
> + sig_on()
> + i = glp_eval_tab_row(self.lp, k + 1, c_indices, c_values)
> + sig_off()
> + except Exception:
> + sage_free(c_indices)
> + sage_free(c_values)
> + raise MIPSolverException('GLPK : basis factorization does
not exist')
> }}}
>
> Indeed, as it catches everything and only raises MIPSolverException, it
can transform a KeyboardInterrupt into a "GLPK: basis factorization does
not exist". And of course the C function `glp_eval_tab_row` cannot be
expected to raise any exception.
>
> I don't think that it is worth adding a sig_on/sig_off in this function,
considering how short it is.
sig_on/sig_off catches all kinds of signals, and here it is used to catch
SIGABRT, which GLPK invokes via abort() whenever there is an error.
Is there a way to distinguish which signal was caught?
--
Ticket URL: <http://trac.sagemath.org/ticket/18732#comment:10>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
