matrix subdivision question
gerhard
let M be a matrix over QQ:
subdivisions are printed fine
over GF(2):
M.get_subdivisions() shows the subdivisions are defined,
but the print method does not know about them.
The show methods cannot handle subdivisions altogether.
This is a pity since I was using sage with sagetex
to generate the matrices...
Are there any plans to enhance these printing methods?
thanks,
-gerhard
Justin C. Walker
On Apr 8, 2009, at 12:07 , gerhard wrote:
> Print methods for matrices with subdivisions
>
> let M be a matrix over QQ:
> subdivisions are printed fine
> over GF(2):
> M.get_subdivisions() shows the subdivisions are defined,
> but the print method does not know about them.
Yup. Most matrix classes seem to use a common method for printing,
while the 'mod 2' matrix implementation has its own "stringify" method.
There may be a good explanation for this, but commenting out the mod2
method seems to have the right effect without damaging anything else.
At least with minimal testing.
> The show methods cannot handle subdivisions altogether.
I'm not sure I understand. For other than the mod 2 elements, show(X)
produces an image of a subdivided matrix. Do you mean just in the mod
2 case?
> Are there any plans to enhance these printing methods?
I think it qualifies as a bug, and I've created a Trac report for the
problem:
<http://trac.sagemath.org/sage_trac/ticket/5714>
Thanks for reporting this.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Director
Institute for the Enhancement of the Director's Income
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
William Stein
>
>
> On Apr 8, 2009, at 12:07 , gerhard wrote:
>
>> Print methods for matrices with subdivisions
>>
>> let M be a matrix over QQ:
>> subdivisions are printed fine
>> over GF(2):
>> M.get_subdivisions() shows the subdivisions are defined,
>> but the print method does not know about them.
>
> Yup. Most matrix classes seem to use a common method for printing,
> while the 'mod 2' matrix implementation has its own "stringify" method.
>
> There may be a good explanation for this, but commenting out the mod2
> method seems to have the right effect without damaging anything else.
> At least with minimal testing.
>
>> The show methods cannot handle subdivisions altogether.
>
> I'm not sure I understand. For other than the mod 2 elements, show(X)
> produces an image of a subdivided matrix. Do you mean just in the mod
> 2 case?
>
>> Are there any plans to enhance these printing methods?
>
> I think it qualifies as a bug, and I've created a Trac report for the
> problem:
> <http://trac.sagemath.org/sage_trac/ticket/5714>
>
> Thanks for reporting this.
I made another related ticket, since subdivision lifting
is broken:
John H Palmieri
On Apr 8, 12:56 pm, "Justin C. Walker" <jus...@mac.com> wrote:
> On Apr 8, 2009, at 12:07 , gerhard wrote:
>
> > Print methods for matrices with subdivisions
>
> > let M be a matrix over QQ:
> > subdivisions are printed fine
> > over GF(2):
> > M.get_subdivisions() shows the subdivisions are defined,
> > but the print method does not know about them.
>
> Yup. Most matrix classes seem to use a common method for printing,
> while the 'mod 2' matrix implementation has its own "stringify" method.
>
> There may be a good explanation for this, but commenting out the mod2
> method seems to have the right effect without damaging anything else.
> At least with minimal testing.
sage: MS = M.sparse_matrix()
sage: MS.subdivide(2,3)
The subdivisions in MS should appear: the problem is only in dense
matrices over GF(2).
> > The show methods cannot handle subdivisions altogether.
>
> I'm not sure I understand. For other than the mod 2 elements, show(X)
> produces an image of a subdivided matrix. Do you mean just in the mod
> 2 case?
>
> > Are there any plans to enhance these printing methods?
>
> I think it qualifies as a bug, and I've created a Trac report for the
> problem:
> <http://trac.sagemath.org/sage_trac/ticket/5714>
I also created a ticket, <http://trac.sagemath.org/sage_trac/ticket/
5715>, with a patch, deleting the str method for dense mod 2
matrices.
John H Palmieri
William Stein
Neither Justin nor I have a patch, and I don't think either of us are
working on one.
I posted this on your patch, which slows str down by a factor of 12
(in this example):
Needs work. There is a *very good* reason that there is a str method
for GF(2) -- it's for speed! Check this out:
{{{
BEFORE YOUR PATCH:
sage: a = random_matrix(GF(2),1000)
sage: time b = a.str()
CPU times: user 0.41 s, sys: 0.01 s, total: 0.42 s
Wall time: 0.42 s
}}}
{{{
AFTER YOUR PATCH:
sage: a = random_matrix(GF(2),1000)
sage: time b = a.str()
CPU times: user 5.02 s, sys: 0.86 s, total: 5.88 s
Wall time: 5.89 s
}}}
gerhard
M.subdivide(1,3);
print M.get_subdivisions()
show(M)
I get
([1], [3])
as for the show method output, no subdivisions.
latex(M) yields
\left(\begin{array}{rrr|rrrrrrrrrrrrrrrrr}
1 & 1 & 0 & 0 & 1 & 1 & 1 & 0 & 0 &
0 & 0 & 0 & 1 & 0 & 1 & 0 & 1 & 0 &
0 & 0 \\
0 & 1 & 1 & 0 & 0 & 1 & 0 & 1 & 0 &
0 & 0 & 0 & 0 & 1 & 1 & 1 & 0 & 0 &
1 & 1
\end{array}\right)
Now, in my firefox browser, I see no subdivisions.
In latex, I see a vertical line after column 3,
but no horizontal line after row 1.
The print method yields bot dividing lines...
-gerhard
John H Palmieri
>
> > I'll mark mine as a duplicate. Go ahead with your patch.
>
> Neither Justin nor I have a patch, and I don't think either of us are
> working on one.
complete (or try again if testing fails)." It sounded from this and
earlier comments on the ticket as though he had a patch and it was
equivalent to mine.
> I posted this on your patch, which slows str down by a factor of 12
> (in this example):
>
> Needs work. There is a *very good* reason that there is a str method
> for GF(2) -- it's for speed! Check this out:
> {{{
> BEFORE YOUR PATCH:
> sage: a = random_matrix(GF(2),1000)
> sage: time b = a.str()
> CPU times: user 0.41 s, sys: 0.01 s, total: 0.42 s
> Wall time: 0.42 s}}}
>
> {{{
> AFTER YOUR PATCH:
> sage: a = random_matrix(GF(2),1000)
> sage: time b = a.str()
> CPU times: user 5.02 s, sys: 0.86 s, total: 5.88 s
> Wall time: 5.89 s
>
> }}}
str function for the mod 2 case?
John
John H Palmieri
of subdivisions of matrices has been broken, but a fix will be in Sage
3.4.1.
Justin C. Walker
On Apr 8, 2009, at 13:29 , John H Palmieri wrote:
>
> On Apr 8, 1:10 pm, William Stein <wst...@gmail.com> wrote:
>> On Wed, Apr 8, 2009 at 1:06 PM, John H Palmieri
>> <jhpalmier...@gmail.com> wrote:
>>
>>> I'll mark mine as a duplicate. Go ahead with your patch.
>>
>> Neither Justin nor I have a patch, and I don't think either of us are
>> working on one.
>
> Justin posted on his ticket "I'll attach a patch when the testing is
> complete (or try again if testing fails)." It sounded from this and
> earlier comments on the ticket as though he had a patch and it was
> equivalent to mine.
Since yours is there, let's use it.
>> I posted this on your patch, which slows str down by a factor of 12
>> (in this example):
>>
>> Needs work. There is a *very good* reason that there is a str method
>> for GF(2) -- it's for speed! Check this out:
>> {{{
>> BEFORE YOUR PATCH:
>> sage: a = random_matrix(GF(2),1000)
>> sage: time b = a.str()
>> CPU times: user 0.41 s, sys: 0.01 s, total: 0.42 s
>> Wall time: 0.42 s}}}
>>
>> {{{
>> AFTER YOUR PATCH:
>> sage: a = random_matrix(GF(2),1000)
>> sage: time b = a.str()
>> CPU times: user 5.02 s, sys: 0.86 s, total: 5.88 s
>> Wall time: 5.89 s
>>
>> }}}
>
> So this means duplicating the subdivisions part of the general matrix
> str function for the mod 2 case?
As a first cut, why not use the local str() method unless subdivisions
are in place. There may be a performance issue in determining the
latter (ISTR that this requires using "try: except:", which is a bit
painful if the 'except' branch is taken).
I had spent some time a while back trying to clean up the subdivision
code, but got waylaid and haven't found my way back to that particular
clearing...
But first things first. We should fix the mod2 case, then worry about
the rest.
I would hazard the guess that non-mod2 'str' processing will suffer
the same performance issue, so maybe fix all at the same time? I.e.,
support subdivisions for mod2 strings and improve performance for non-
mod2 strings.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------
Robert Bradshaw
>> So this means duplicating the subdivisions part of the general matrix
>> str function for the mod 2 case?
>
> As a first cut, why not use the local str() method unless subdivisions
> are in place. There may be a performance issue in determining the
> latter (ISTR that this requires using "try: except:", which is a bit
> painful if the 'except' branch is taken).
It's not to messy except when multiple subdivision occur in a row.
> I had spent some time a while back trying to clean up the subdivision
> code, but got waylaid and haven't found my way back to that particular
> clearing...
>
> But first things first. We should fix the mod2 case, then worry about
> the rest.
I posted a different patch.
> I would hazard the guess that non-mod2 'str' processing will suffer
> the same performance issue, so maybe fix all at the same time? I.e.,
> support subdivisions for mod2 strings and improve performance for non-
> mod2 strings.
I think the issue is that the generic code extracts and calls str on
each element, which isn't needed in the specialized mod2 case. (It
also does work to make all entries aligned.)
- Robert