#15438: Fix elias_upper_bound
---------------------------------+----------------------------
Reporter: pmueller | Owner: pmueller
Type: defect | Status: needs_review
Priority: minor | Milestone: sage-5.13
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
---------------------------------+----------------------------
Comment (by pmueller):
Replying to [comment:4 ppurka]:
> Replying to [comment:3 pmueller]:
> > I just see that there are more problems in the file code_bounds.py.
For instance, something like `codesize_upper_bound(10,1,2)` raises an
error because it looks for the minimum of the various bounds, but some of
them (plotkin, elias) are not defined for these parameters. I think if
`elias/plotkin_upper_bound(n, q, d)` isn't defined, it should return a
trivial bound like `q^n` instead of an error.
>
> I think it should raise a `ValueError` instead. A trivial bound would
give the incorrect impression that the bound is well defined for those
parameters.
I prefer a true but trivial bound instead, so that one does not have to
care about an allowed choice of parameters.
>
> > While these things, like the original mistake in the
`elias_upper_bound`, are easy to fix, I'm a little concerned with the
order of arguments. Is there any reason to have for instance
`hamming_upper_bound(n, q, d)`, but `q` and `d` switched in
`delsarte_bound_hamming_space(n, d, q)` and `codesize_upper_bound(n, d,
q)`?
> >
> > In my opinion that's a perfect and unnecessary source for producing
errors. However, making things consistent would break compatibility, so
maybe the only way out is to keep the present functions, and use new names
for those with consistent argument orders.
>
> I think the order of those commands should be fixed once and for all.
And a `warning` printed for a year (that is the usual period for
deprecation, but we can't deprecate anything here).
I strongly disagree! If we change the order of arguments without changing
the function names, then code which was correct will become incorrect in
future versions of Sage. I just see another problem: In
elias_bound_asymp(delta, q) we *first* have d (via delta) and then q,
while in elias_upper_bound(n, q, d) it is the other way around. So maybe
we drop the redundant *upper* in the function names, and replace
elias/plotkin/etc_upper_bound(n, q, d) by elias/plotkin/etc_bound(n, d,
q). Then the naming is consistent with the asymptotic and the delsarte
functions.
--
Ticket URL: <http://trac.sagemath.org/ticket/15438#comment:7>
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/groups/opt_out.
