New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A coding/two_weight_db module #19463
Comments
Commit: |
comment:1
What the hell. I made a mistake and was dead sure I had deleted that branch that took me hours. Praise the Lord for 'git reflog' [1] Nathann [1] http://stackoverflow.com/questions/3640764/can-i-recover-branch-after-its-deletion-in-git New commits:
|
Branch: u/ncohen/19463 |
comment:2
in [BJ03], you get name wrong; it is |
comment:3
The code should be capable of telling whether an SRG with such and such parameters can be constructed merely from knowledge of parameters of two-weight codes available in the DB. Currently this is not implemented, partly due to an error in the formulas on http://moodle.tec.hkr.se/~chen/research/2-weight-codes/index.htm |
comment:4
Isn't there a simpler way of getting the set of weights than
You are going through the whole set of vectors! But I admit that the module is not imported on sage startup. One possibility: hard code the values + add a (long) doctest that checks that these values are indeed correct? |
comment:5
... and note that there is |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:7
Fixed.
I now call
That was done in an early version of this patch. I removed it to not see data repeated. I guess that it cannot hurt... All this code may eventually be wiped out however, if we start adding generic code constructions instead of fixed-size examples. That will probably change all the design, but well. We'll see. Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:9
Replying to @videlec:
I was thinking that it would be nice to refactor the DB by creating a class I would give this class a flag at construction time Johan |
comment:10
I have no objection to that if you plan to do it yourself. Nathann |
comment:11
To be more precise: this is a trac ticket. What is going here is a review, and I read anything that is written here as a comment about my code. When somebody says here that "it would be cool if your code did this/that" I read it as a comment from a reviewer. Could you make it clear whether you were asking me to implement it, or is it a random idea you were throwing here? Nathann |
comment:12
I wrote it as a "random idea". I am somewhat motivated to do it myself, but realistically, I might well not find time to do it. I have no objections to your code if no one else wants to implement my suggestion. It was also a comment to Vincent's suggestion. Something like: what he suggests opens up a few questions IMHO, and to properly cater all that, one needs a more invasive restructuring of your code. In that sense it was a defence of your code as it's currently written. Johan |
comment:13
I expect all this code to be totally wiped out and rewritten in the future. As you saw in the emails I sent about 2-weight codes the plan is to make it the 'new database' for those objects, and from what Eric Chen was saying it seems that all these codes belong to known families that we will be able to generate easily later. I do not know what this code will look like, if it will totally replace what we have or only replace it partially, and how soon this will be implemented. What I did here is extract the codes from the strongly regular graph module, in what will eventually become an independent database. Which, for the moment, is nothing but a dictionary with a bit of doc. Nathann |
comment:14
My suggestion would make even more sense in this case, almost no matter how the future code will be written. Encapsulating the two-weight code properties and algorithms in a class is much more tidy and more easily supports computing things on demand. |
comment:15
Which properties and algorithms are you talking about? Nathann |
comment:16
Replying to @nathanncohen:
see the examples in http://pages.uoregon.edu/kantor/PAPERS/2-WeightCodes.pdf |
comment:17
I just love conversing with you guys. I ask one person what properties/algorithms he would expect to see in a If you have any question about the code under review here, I will be glad to help. Nathann |
comment:18
Replying to @nathanncohen:
well, I meant algorithms to build all these... Disclaimer: I am not a coding theorist and I know almost nothing about all these marvellous practical things about decoding/encoding, etc... |
comment:19
Oh. Well, that was not the topic. As you can read, we were discussing the usefulness of a specific class for two weight codes. 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. Nathann |
comment:20
Probably it makes sense to make a sub-class for projective codes, for a q-ary [n,k]-projective code naturally corresponds to a set in PG(k-1, q), to which one can do things not possible with general codes. But 2-distance? Well, I don't know. |
comment:21
Replying to @nathanncohen:
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 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 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 :-) |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:34
Fixed. Thanks, Nathann |
comment:35
Replying to @nathanncohen:
I told you - take the last commit :-) |
comment:36
I don't quite understand the new design, but it seems to work. |
Reviewer: Dima Pasechnik |
comment:38
Merge conflict |
Changed branch from u/ncohen/19463 to public/19463 |
comment:40
the merge conflict was in the .rst file, trivial to resolve. I hope I didn't screw up the branch I propose... |
Changed branch from public/19463 to u/ncohen/19463 |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:43
This new commit only merges it with beta6, and not with anything else. |
Changed branch from u/ncohen/19463 to |
Changed commit from |
comment:45
There is still a two-weight code left in
|
comment:46
I didn't know that commenting on closed tickets looks like it nukes commits. I think it's actually just a wrong message, as I can still see this commit just fine. |
This ticket creates a new coding/two_weight_db module.
In it are stored all codes that were stored in graphs/strongly_regular_db.pyx. I expect that this file will change heavily, if we end up enriching our list of two weight codes for their own sake.
A first commit moves out of the
strongly_regular_graph
function the code that builds the database of small strongly regular graphs. Which turned out to be a good idea later, as building this list actually takes some time in order to guess the parameters of the SRG from the 2-weight code.Nathann
Depends on #19624
CC: @johanrosenkilde @sagetrac-dlucas @dimpase
Component: coding theory
Author: Nathann Cohen
Branch:
a865eb3
Reviewer: Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/19463
The text was updated successfully, but these errors were encountered: