#19340: Better interface for hadamard_matrix
-------------------------------------+-------------------------------------
Reporter: ncohen | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.9
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Nathann Cohen | Work issues:
Report Upstream: N/A | Commit:
Branch: u/ncohen/19340 | 247a2bb4dcec180227cd9fb9bcd331a27a289016
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by fredrik.johansson):
Replying to [comment:7 ncohen]:
> > You might consider using the flint functions fmpz_mat_hadamard and
fmpz_mat_is_hadamard, which should be faster.
>
> How easily can I call them on a Sage matrix?
It should be enough to add the following declarations in
libs/flint/fmpz_mat.pxd
{{{
int fmpz_mat_hadamard(fmpz_mat_t A)
int fmpz_mat_is_hadamard(const fmpz_mat_t A)
}}}
and the following methods in matrix/matrix_integer_dense.pyx
{{{
def _hadamard(self):
# in-place, returns whether successful
return fmpz_mat_hadamard(self._matrix)
def is_hadamard(self):
return fmpz_mat_is_hadamard(self._matrix)
}}}
Then you can do something like this in hadamard_matrix()
{{{
if not(n % 4 == 0) and (n > 2):
raise ValueError
mat = Matrix(ZZ, n, n)
if mat._hadamard():
return mat
else:
# use database here
raise ValueError
}}}
> > Checking by default seems kind of useless since this is much slower
than generating the matrix (generating a size 1000 Hadamard matrix takes
0.01 seconds and checking it takes 0.5 seconds), and unit testing should
provide reasonable certainty that the algorithm is correct.
>
> Sorry to disappoint, but I have thousands of line behind me (in
combinat/designs/) that implement old combinatorial designs from lost
papers. I know the value of this kind of testing.
You may well be right about combinatorial designs in general. But, having
written the flint code, and considering that it implements a fairly simple
algorithm, when it's already exhaustively tested up to size 300, I think
it's highly unlikely to give an incorrect matrix for larger sizes. So I
can't agree with slowing it down many orders of magnitude by default.
> > Flint's test suite already checks for every size up to 300 that
fmpz_mat_hadamard either constructs a correct Hadamard matrix or reports
that the size is unsupported.
>
> Are you saying that flint can be easily accessed from Sage *and* that it
contains a database of hadamard matrices? If so, I woulld be glad to call
it from the general constructor of hadamard matrices in Sage.
It doesn't have a database; it uses the Paley construction. As noted
above, you can easily use a fallback database/algorithm if it fails.
BTW, fmpz_mat_hadamard succeeds for every multiple of 4 up to 92; current
code for the Paley construction in Sage doesn't succeed to construct a
size 20 Hadamard matrix.
--
Ticket URL: <http://trac.sagemath.org/ticket/19340#comment:8>
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.
