Opened 6 years ago

Closed 6 years ago

#19624 closed enhancement (fixed)

two more srgs from Hoffman-Singleton family

Reported by: dimpase Owned by:
Priority: major Milestone: sage-6.10
Component: graph theory Keywords:
Cc: ncohen Merged in:
Authors: Dima Pasechnik Reviewers: Nathann Cohen
Report Upstream: N/A Work issues:
Branch: 9a02f68 (Commits, GitHub, GitLab) Commit: 9a02f68e397641c0774175e495350e47c2a88908
Dependencies: Stopgaps:

Status badges

Description (last modified by dimpase)

construct srg's with parameters (176, 90, 38, 54) and (630, 85, 20, 10) following the description in Sect. 10.B of [BvL84].

Attachments (1)

g176.sage (911 bytes) - added by dimpase 6 years ago.
Sage script to get them

Download all attachments as: .zip

Change History (16)

comment:1 Changed 6 years ago by dimpase

two more to bite the dust...

Changed 6 years ago by dimpase

Sage script to get them

comment:2 Changed 6 years ago by ncohen

Coooooooool :-P

Nathann

comment:3 follow-up: Changed 6 years ago by ncohen

Would you mind my adding #19463 as a dependency of this? Modifying the list of small SRG in any way creates a conflict with it :-/

comment:4 in reply to: ↑ 3 ; follow-up: Changed 6 years ago by dimpase

  • Branch set to u/dimpase/hsfamily
  • Commit set to 4c576267fe44be321179cea5b49bfc8ba9090bdf
  • Description modified (diff)
  • Status changed from new to needs_review

Replying to ncohen:

Would you mind my adding #19463 as a dependency of this? Modifying the list of small SRG in any way creates a conflict with it :-/

I'd rather have it the opposite way - this ticket is ready to review, and it's a trivial one, as opposed to #19463.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 6 years ago by ncohen

I'd rather have it the opposite way - this ticket is ready to review, and it's a trivial one, as opposed to #19463.

Well yeah but there is a conflict to fix, and both tickets will have to be merged anyway. If you fix the conflict I don't mind.

Nathann

comment:6 in reply to: ↑ 5 ; follow-up: Changed 6 years ago by dimpase

Replying to ncohen:

I'd rather have it the opposite way - this ticket is ready to review, and it's a trivial one, as opposed to #19463.

Well yeah but there is a conflict to fix, and both tickets will have to be merged anyway. If you fix the conflict I don't mind.

I didn't know that #19463 is ready (there was a notice "not to be merged..." there for some time) when I sat down this morning to work on this ticket, sorry. I can try to merge the stuff, but you know what you did there much better, and I guess it would take you much less time (I don't mind this ticket becoming dependent on #19463, I just don't know exactly what should go where...)

Let me know how you'd like to proceed.

comment:7 in reply to: ↑ 6 Changed 6 years ago by ncohen

Hello,

I didn't know that #19463 is ready (there was a notice "not to be merged..." there for some time) when I sat down this morning to work on this ticket, sorry.

Well, the 'not to be merged' did not mean 'not to be reviewed'. It means that I knew it would conflict with other things and that the merging required a double-check before being merged, or constructions would be 'lost'. I did this double check yesterday evening when I removed the note, and knowing that no other constructions are one the way (until you opened a new one), it was safe again 'to merge'. But it has been 'safe to review' since the beginning.

I can try to merge the stuff, but you know what you did there much better, and I guess it would take you much less time (I don't mind this ticket becoming dependent on #19463, I just don't know exactly what should go where...)

Ideally, #19463 would be reviewed first (it has been in needs_review for 5 weeks). Then, instead of adding your line where the long list of constructions used to be, you would have to add it where it is after that branch is applied.

Let me know how you'd like to proceed.

I'll handle the merge to not turn this into another war, but please don't make this fix this conflict again.

Nathann

comment:8 Changed 6 years ago by ncohen

Hello Dima,

The code of SRG_176_90_38_54 is a bit dirty, and I am not convinced that it would even work if the output of maximal_cliques was given in a different order. Could you try building the hypergraph of those cliques and asking for a packing of it? If GLPK finds it easily then there is no reason to make matters more complicated.

Also this

-from sage.graphs.strongly_regular_db import SRG_175_72_20_36

You do not need it if you are in the same module.

Nathann

comment:9 Changed 6 years ago by ncohen

+    assert(hs.subgraph(mc).degree()==[0]*15) # a maximum coclique
+    assert(hs.subgraph(P).degree()==[3]*10)

You have Graph.is_regular(k=whatever) for these situations.

Nathann

comment:10 Changed 6 years ago by dimpase

At this point I am not sure whether I should provide changes you'd like to see here on u/dimpase/hsfamily rather than on public/19463.

Seems to be double work to do it on u/dimpase/hsfamily -- unless I misunderstand how git works...

comment:11 Changed 6 years ago by ncohen

You can add commits here. Not *all* commits from here need to be merged with #19463. Only those that may create conflict must.

If you modify files from finance/ in this branch, there is no need to synchronize the two.

Update this branch however you like. Just don't rewrite history (or change a space in the listing of small graphs from strongly_regular_db) and all will be fine.

Nathann

comment:12 Changed 6 years ago by git

  • Commit changed from 4c576267fe44be321179cea5b49bfc8ba9090bdf to 9a02f68e397641c0774175e495350e47c2a88908

Branch pushed to git repo; I updated commit sha1. New commits:

9a02f68the fixes requested

comment:13 Changed 6 years ago by dimpase

OK, here are the fixes. Not sure if this will need more merging action on #19463, but at least this ticket looks done.

comment:14 Changed 6 years ago by ncohen

  • Authors set to Dima Pasechnik
  • Reviewers set to Nathann Cohen
  • Status changed from needs_review to positive_review

Works for me,

Nathann

comment:15 Changed 6 years ago by vbraun

  • Branch changed from u/dimpase/hsfamily to 9a02f68e397641c0774175e495350e47c2a88908
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.