#19623: Syndrome decoder is not a syndrome decoder
-------------------------------------+-------------------------------------
Reporter: dlucas | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.0
Component: coding theory | Resolution:
Keywords: | Merged in:
Authors: David Lucas | Reviewers: Julien Lavauzelle
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/dlucas/generic_decoders | 54c02c3af22e896dd03759408b989f493415f26a
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by dlucas):
Another question:
For now, `_build_lookup_table` is called on the first decoding attempt,
and not at construction time.
I made this choice, because, as a user, I prefer objects I use to be
constructed quickly, and then spend some time when calling methods over
this objects rather than waiting at construction time. It's a matter of
taste I guess. Also, I might be working in a very strange way for which I
need to construct decoders but not using their decoding methods. From this
point of view, the faster the better.
Anyway, here we have the following behaviour:
- I build my decoder.
- If I call directly `maximum_error_weight()`, `decoding_radius()` or
representation methods, it will return me results based on either the
value I chose for `maximum_error_weight` or `n-k` depending on which is
the lowest.
- Then I perform some decoding, call the methods I listed above again, and
their output might have change... The same occurs with `decoder_type()`.
From the user point of view, it can be quite confusing (imho).
So, wouldn't it be better to build the lookup table at construction time,
so "internal" `minimum_distance` and `covering_radius` might be found (if
possible) and results updated accordingly?
In that configuration, whenever I call representations methods,
`decoder_type` and so on, their output will remain the same.
What do you think?
--
Ticket URL: <http://trac.sagemath.org/ticket/19623#comment:24>
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.
