#19463: A coding/two_weight_db module
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_review
Type: | Milestone: sage-6.10
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
coding theory | Work issues:
Keywords: | Commit:
Authors: | 73930f28c0d15ac1cbe1b6fd2741817608dec0ec
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/19463 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by jsrn):
Replying to [comment:19 ncohen]:
> > well, I meant algorithms to build all these...
>
> While I hold nothing against it, I wondered why Johan thought that it
would be useful: I personally just need the codes to build strongly
regular graphs. I don't know which properties/methods we would attach to
them if we had such a class.
A class is just a dictionary with code attached to it :-) Two-weight codes
are special codes that allow certain properties to be calculated much
faster than the general exponential bounds. Such as, obviously, minimum
distance and which hamming weights are in the code, but there's surely
more. Since such codes are apparently interesting in graph theory and
combinatorics, it seems likely that someone might want to play around with
them as codes, before you build graphs. "playing around" would then be
computing stuff on them. Making them a class would give a natural place to
put this code. By just making them `LinearCode`s, we miss out on the
opportunity of putting these fast algorithms in a natural place. I'm not
really talking about encoding/decoding, since I don't know that anyone
should be interested in that.
One concrete example in your use where a class might be useful is in lazy
computation of the two weights, using the faster, probabilistic algorithm.
The constructions of families that Dima talks about could be either
functions that instantiate `TwoWeightCode` or subclasses, depending on
whether the first would be overkill or not.
I outlined above. I concede that it might look like over-engineering from
your point of view, however. From my point of view, this is a very special
class of codes that is seemingly useful and (now) used in Sage. Therefore
its natural that it should have a class :-)
--
Ticket URL: <http://trac.sagemath.org/ticket/19463#comment:21>
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/d/optout.
