#15285: Bug in AffineGeometryDesign
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_review
Type: | Milestone: sage-6.1
defect | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
combinatorics | Work issues:
Keywords: | Commit:
Authors: | 8468131a81898d5a3ccfb38d9f1a3d44df15fe10
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
u/ncohen/15285 |
Dependencies: |
#15107 |
-------------------------+-------------------------------------------------
Comment (by ncohen):
Yooooo !
> Let me re-ask my question, trying to be more clear.
>
> '''After the commits''' (and before also), the doctests show that
>
> `.parameters` and `.is_block_design` give the same numbers for
`AffineGeometryDesign(3, 1, GF(2))`
>
> but not for `AffineGeometryDesign(3, 2, GF(2))`
>
> Why is it so ? Are they supposed to always give the same result ?
`O_o`
Well, I have absolutely no idea. I don't use this `BlockDesign` class.
Hmmmmmm.. Let me see.
The docstring of `parameters` says that it does not check if the input is
a block design (which can be costly). It just counts the number of blocks.
And I am reading the code of `is_block_design` right now but I don't
actually get it.
For the record
{{{
sage: IncidenceStructure([0,1],[[0,1]]*15).parameters()
(2, 2, 2, 15)
sage: IncidenceStructure([0,1],[[0,1]]*15).is_block_design()
...
UnboundLocalError: local variable 't' referenced before assignment
}}}
And there, they do not return the same
{{{
sage: IncidenceStructure([0,1,2],[[0,1],[0,2],[1,2]]*15).is_block_design()
(True, [1, 3, 2, 15])
sage: IncidenceStructure([0,1,2],[[0,1],[0,2],[1,2]]*15).parameters()
(2, 3, 2, 15)
}}}
Oh, I finally understand what you said ! And why you talked of this `t`.
Well, I guess that both functions should always return the same, except
when the incidence structure is not really a block design. Which
`parameters` is not supposed to notice.
But they should agree on this `t` anyway. Especially if they agree on all
other coordinates. And it looks like `is_block_design` is the one that is
wrong here.
Hmmmm...
Well it seems wrong but I really do not understand what the code does. And
this `range(2, min(v, 11))` definitely looks like a cheap trick to not do
anything if `t` is larger than 11...
Actually, I do not understand why this function does not call `parameter`
to guess the value of `t,v,k,lambda`, then checks that the incidence
structure is indeed such a design.
That's all I can say right now. I really don't understand the part of the
code included in this `for` loop on `t`.
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/15285#comment:6>
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/groups/opt_out.
