#20447: Wrong result from delsarte_bound_additive_hamming_space with GLPK exact
simplex
-------------------------------------------------+-------------------------
       Reporter:  mkoeppe                        |        Owner:
           Type:  defect                         |       Status:
       Priority:  major                          |  needs_info
      Component:  coding theory                  |    Milestone:  sage-7.2
       Keywords:  lp                             |   Resolution:
        Authors:                                 |    Merged in:
Report Upstream:  Not yet reported upstream;     |    Reviewers:
  Will do shortly.                               |  Work issues:
         Branch:                                 |       Commit:
   Dependencies:  #20406                         |     Stopgaps:
-------------------------------------------------+-------------------------

Comment (by mkoeppe):

 Replying to [comment:8 dimpase]:
 > Replying to [comment:7 mkoeppe]:
 > > Replying to [comment:6 dimpase]:
 > > > I don't think there is an API to check whether a solver is exact,
 and so I never bothered to check this in the code.
 > >
 > > You can query the `base_ring` of the MIP and then ask `is_exact`.
 >
 > well, `is_exact` is a bit too much to ask, one merely needs extra
 precision.
 > (one can figure out how much, in fact).
 > So you can use a backend that allows you to set the base ring to e.g.
 `RealField(2000)`.

 Perhaps you mean a `RealIntervalField` here, because certainly
 `RealField(2000)` does not guarantee that the result of some unspecified
 numerical algorithm such as the implementation of the simplex method in
 the solver leads to results with 2000 correct bits, just like double-
 floats don't guarantee 53 correct bits.

 > Besides, I don't think there are places in Sage that forbid doing things
 cause they are "risky".

 I think there more places should forbid things like that, or at least
 display a warning. For example, the polyhedral code in Sage is written in
 a way that it assumes exact arithmetic -- and if fed with floating point
 numbers, leads to mysterious errors. One would usually assume from
 algorithms that accept floating point numbers that they have some (however
 naive) accommodation for floating point fuzz, in the form of some
 epsilons.

--
Ticket URL: <http://trac.sagemath.org/ticket/20447#comment:9>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to