On 12/15/2013 08:10 PM, Peter Mueller wrote:
    I think isinteger probably makes sense for the
    delsarte_bound_additive_hamming_space() function.

Of course it does. But this function is dedicated to codes which are
abelian groups, so the weight distribution coincides with the distance
distribution. I didn't say that I have concerns with this function.

Well, what I meant is exactly what you stated in your mail below - that the usual delsarte_bound should not contain the isinteger keyword. Maybe Dima has some input on it. (CC'd)

    The LP solver used should give exact results and not have any floating
    point problems. See http://trac.sagemath.org/ticket/12533
    <http://trac.sagemath.org/ticket/12533>

  As far as I know, PPL is the only exact LP solver which Sage uses.
However, this backend doesn't have an IP solver. I see that the stand
alone solver glpsol  has the option --exact, but I do not know if this
is used in IP problems. And I do not know if Sage can use this in its
GLPK backend. As you apparently know more about the Sage capabilities to
exactly solve IP problems, it would be nice if you share your knowledge
here.

The PPL backend does not work with integer variables. The GLPK backend does. You can look at the documentation of the ppl backend, though I guess you already know this:
http://www.sagemath.org/doc/reference/numerical/sage/numerical/backends/ppl_backend.html

    I am not sure why there would be improvements to the tables. Someone
    would have noticed such improvements earlier, right?

What's that supposed to mean?

There has been quite a bit of work earlier on determining these bounds. I would be surprised if we started getting "improved" results for such low numbers as you have stated below.

 Here is an example: Let A(n,d) be the
largest size of a binary code of length n and minimal distance >=d. The
best know upper bound according to Agrell's table
<http://webfiles.portal.chalmers.se/s2/research/kit/bounds/unr.html> for
A(17,3) is 6552, while delsarte_bound_hamming_space(17, 3, 2
,isinteger=True, solver="glpk") gives the *better* bound 6464! There are
many more examples like this.

I think there might be something funny going on with the GLPK backend.
This should hold true: A(17, 3) = A(18, 4), so let's compare the two.

sage: delsarte_bound_hamming_space(18, 4, 2, True, solver="GLPK")
6532.0
sage: delsarte_bound_hamming_space(17, 3, 2, True, solver="GLPK")
6464.0

These two are really very different results. Now, let us compare the values when isinteger is set to false.

sage: delsarte_bound_hamming_space(18, 4, 2, False, solver="glpk")
6553.600000000002
sage: delsarte_bound_hamming_space(17, 3, 2, False, solver="glpk")
6553.5999999999985

That's pretty close, and it compares well with the PPL backend:

sage: delsarte_bound_hamming_space(18, 4, 2, False, solver="PPL").n()
6553.60000000000
sage: delsarte_bound_hamming_space(17, 3, 2, False, solver="PPL").n()
6553.60000000000



    [...] Sorry, my question was (obviously) the opposite - when does
    isinteger=True give a *smaller* number compared to isinteger=False.

In many cases! If that were not the case, there would be no point
offering the slow isinteger=True option at all. And indeed, for additive
codes it is nice to have these stronger bounds, even if they are only
correct up to numerical issues.

What I tried to say in my initial message was that I believe that for
non-additive codes, the option isinteger=True internally makes the
mathematically unjustified assumption that the distance distribution
consists of integers, or that the Delsarte inequalities do hold also for
the weight distribution. So if this function uses a false assumption,
this option should be removed.

-- Peter Mueller


--
You received this message because you are subscribed to the Google
Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to