#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 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.
> Furthermore, is `RR(fact)==RR(int(fact))` the right way to check if the
rational number `fact` is an integer?
I agree that that is a really bad way to check for an integer. It should
be `isinstance(fact, (ZZ, int, long))`.
> 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).
--
Ticket URL: <http://trac.sagemath.org/ticket/15438#comment:4>
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.
