#3943: pydesign patch [not ready for review]
---------------------------+------------------------------------------------
Reporter: wdj | Owner: wdj
Type: enhancement | Status: new
Priority: major | Milestone: sage-combinat
Component: combinatorics | Resolution:
Keywords: |
---------------------------+------------------------------------------------
Comment (by rlm):
> (1) How is a block design a nonlinear binary code? Via its incidence
matrix?
Correct.
> If yes, then users who wish to "play" with block designs using Sage will
want commands which are fairly intuitive.
I agree. Optimally, a `BlockDesign` class would extend a more general
`IncidenceStructure` class, and much of the functionality would go in
there. Incidentally, "incidence structure" is yet another word for
hypergraph/nonlinear binary code... Without polish, the pydesign classes
don't hold up to the current standards for inclusion into Sage, and the
`BaseBlockDesign` class itself doesn't seem to provide much functionality.
It seems much smarter to implement these things "the Sage way," porting
the needed functions from pydesign.
> ... the automorphism of a block design is computed using NICE, so that
function *does* call Cython.
> Should I rewrite it to the new matrix automorphism function?
You should probably be using the nonlinear binary code routines for this
(you should only use the matrix automorphism routines for matrices which
have more than 0 and 1 as entries), as they would probably be the fastest.
Certainly faster than NICE, since these routines know not to include the
blocks in the partitions which determine the search tree (I can explain a
little more if you want...).
> (3) I'm happy to scrap the XML stuff for now and maybe add it back in
later. I don't really understand how they use that interface anyway.
In my opinion, the way block designs are stored (in XML) is about the
least efficient way possible. For example, the Fano plane looks like this
(snipped from one of the patches):
{{{
BD.xml(name="Fano plane")
219 <?xml version="1.0"?>
220 <block design
221 b="7"
222 id="Fano plane"
223 v="7">
224 <blocks ordered="true">
225 <block>
226 <z>0</z>
227 <z>1</z>
228 <z>2</z>
229 </block>
230 <block>
231 <z>0</z>
232 <z>3</z>
233 <z>4</z>
234 </block>
235 <block>
236 <z>0</z>
237 <z>5</z>
238 <z>6</z>
239 </block>
240 <block>
241 <z>1</z>
242 <z>3</z>
243 <z>5</z>
244 </block>
245 <block>
246 <z>1</z>
247 <z>4</z>
248 <z>6</z>
249 </block>
250 <block>
251 <z>2</z>
252 <z>3</z>
253 <z>6</z>
254 </block>
255 <block>
256 <z>2</z>
257 <z>4</z>
258 <z>5</z>
259 </block>
260 </blocks>
261 </block design>
}}}
Once people start using large block designs, this would be completely
ridiculous. That's three whole lines for one block on seven points-- this
should fit into at most one byte!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/3943#comment:5>
SAGE <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
