#16802: difference family database
-------------------------------------+-------------------------------------
Reporter: vdelecroix | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone:
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Vincent Delecroix | Work issues:
Report Upstream: N/A | Commit:
Branch: | e8984623ba5c4b181971e0524ca47dbe9cc204fc
u/vdelecroix/16802 | Stopgaps:
Dependencies: #16757 |
-------------------------------------+-------------------------------------
Changes (by ncohen):
* status: needs_review => needs_work
Comment:
Yooooooooooooooooooooooooooooo !!!!
First review of this patch (it will be clearer after those points have
been solved):
- The DF in the database: why add a 'S' in the *blocks* of short groups ?
it is
not like it is hard to check that a block has an non-empty stabilizer.
We can
get this info easily. Plus those 'S' have nothing to do in the blocks of
a
design ...
- The database looks a bit messy as it is. Could you align some stuff,
like the ':' or the ',' so that one can actually read it in the code ?
- The database should be indexed with `(v,k,l)` instead of
`((v1,v2,v3),k,l)`. You can have something like that:
{{{
DF_database = {
(v,k,l) : {
(v1,v2,v3): [DF1,DF2,DF3,....]
}
}
}}}
This way you can easily check whether there exists a BIBD that can be
obtained from a difference family. And you can also find `(v1,v2,v3)`
easily.
- With a database indexed with `(v,k,l)` you can undo those modifications
{{{
-if (v,k,l) in DF_constructions:
+G_df = DF_from_database(v,k,l,short_blocks=short_blocks)
+if G_df:
}}}
- Block stabilizer: instead of computing the stabilizer of blocks, you
could
just develop a block with respect to the group and remove duplicated,
you know
? All it takes is a simple call to `set(...)`. Much easier to
understand, no
questions about where all those group-specific functions should be
implemented...
If you do that you save around 100 lines of code+doc with the three
functions
{{{block_stabilizer, orbit_representatives, partial_differences}}}.
Really I
would have nothing if those functions were group methods, but having to
implement all that just for difference families, and just to avoid a
call to
`set()`, really ?....
Plus there is the "short+non-abelian exception" in
`is_difference_family`,
that wouldn't be needed anymore in this case ....
- If you insist on having all those functions to avoid calling "set" to
simplify
the orbits of a block, and if you want to keep the warning above, you
may also
have to handle the case where the group is a multiplicative+commutative
group.
- (That's going very far just to avoid a `set(...)` `:-P`
- `difference_family` : new `short_blocks` argument. Really, WHY do you
care so
much about short blocks ? They are just blocks whose orbit is smaller,
what's
all the fuss about ? If we give the users access to the database, can't
we
just give them a function that tests if a block is short and let them do
what
they want with it ?
- What's the point of filtering difference families with short blocks
anyway ?
- The checks in `DF_from_database`: if you want to check anything about
the
database, it would be better to do it in the doctests than at runtime
?...
- `DF_from_database`: if you actually need it, should be in
`difference_family.py` not in `database.py`
- isn't "too few" better than "too less" ?
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/16802#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/d/optout.
