[sage-devel] Re: Senseless leading_ methods introduced on all matrices

[Johan S. H. Rosenkilde]

Travis Scrimshaw writes:
>> While it is arguably too rigid to say that this is "senseless" (as I 
>> wrote in the subject),
>
> You already did that, and because you started off calling them "senseless," 
> you have polluted this issue with your heavily loaded question. That is 
> unfair and demeaning.

Yes, I'm guilty, I gave the thread a provocative name to make people
read it...


>> I believe that the use of these functions for 
>> matrices is very narrow.
>
> That is untrue. They are very useful to create any sort of 
> submodule/algebra of the matrix module/algebra to be consistent with all 
> other modules or algebras with a distinguished basis. There is also a 
> natural order on the basis too, so things like triangularity of module 
> morphisms need such methods. So perhaps the field of representation theory 
> and triangularity of morphisms is "very narrow."

Good point, as was Simon's concrete example.

> Let's get rid of hamming_weight for polynomials since polynomials are also 
> extremely central objects that beginners start playing around with. Of 
> course, I am not actually proposing this, but this is in the same spirit.

I disagree that this is in the same spirit: the hamming weight/sparsity
of a polynomial is a readily understandable concept, pertaining to
polynomials directly, whose functionality anyone "playing around" with
polynomials will recognise. As opposed to this, these generic finite
rank module methods seem not useful for matrices themselves, but
primarily as glue in a much more abstract context that you described
above.


>> (this came up during #23619 where we are introducing "leading_matrix" 
>> and "leading_position" for matrices over a univariate polynomial ring.) 
>>
>> I think you should be more explicit with your method names and call the 
> first one leading_term_matrix() and the second one I have no idea why it 
> would do.

I would argue that the burden of explicit method names should be *much
higher* on abstract, inherited methods! While I can see the argument for
preferring "leading_term_matrix" in favour of "leading_matrix", it is
important to keep in mind that this method will only appear for matrices
over univariate polynomials, and the user therefore expects its methods
to be named and behave accordingly.

Compare this with "leading_coefficient" on a matrix; most users would
have no idea what that is before they read the doc, and even then -
since the doc is written with totally different examples in mind - they
have to call that method and perhaps "leading_position" several times
before they can figure it out.


I won't argue further against whether the methods should be there
or not. If several mathematicians feel they are really useful, I'm sure
you're right. But then I would argue that they should be renamed into
something much more precise, or perhaps hidden behind an indirection.
Perhaps something like:

sage: M.as_finite_rank_module.leading_?

(except that this sounds like the matrix becomes a finite rank module
which is nonsense.)

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Senseless leading_ methods introduced on all matrices

[Travis Scrimshaw]

> Compared to Sage 8.0, matrices in Sage 8.1.beta1 now have a host of new 
> methods: 
>
>   - leading_coefficient 
>   - leading_item 
>   - leading_monomial 
>   - leading_support 
>   - leading_term 
>
> These are inherited from the category of finite dimensional modules with 
> basis of which matrix spaces are now members. 
>

As they should be.

>
> The semantics is that an e.g. 3x3 matrix over R is an R-module over the 
> basis 
>
>[1 0 0]  [0 1 0]  [0 0 1] 
>[0 0 0], [0 0 0], [0 0 0], ... 
>[0 0 0]  [0 0 0]  [0 0 0] 
>
> and hence, M.leading_coefficient() on such a matrix returns M[2,2] if 
> this is non-zero, otherwise M[2,1] if this is non-zero, etc. 
>
> While it is arguably too rigid to say that this is "senseless" (as I 
> wrote in the subject),


You already did that, and because you started off calling them "senseless," 
you have polluted this issue with your heavily loaded question. That is 
unfair and demeaning.
 

> I believe that the use of these functions for 
> matrices is very narrow.


That is untrue. They are very useful to create any sort of 
submodule/algebra of the matrix module/algebra to be consistent with all 
other modules or algebras with a distinguished basis. There is also a 
natural order on the basis too, so things like triangularity of module 
morphisms need such methods. So perhaps the field of representation theory 
and triangularity of morphisms is "very narrow."
 

> And since matrices are an extremely central 
> object that beginners immediately start playing around with, it is 
> unfortunate that they will pollute the tab-completion to such a degree, 
> and with doc strings which are not very helpful to the algebraically 
> uninitiated.  
>

Let's get rid of hamming_weight for polynomials since polynomials are also 
extremely central objects that beginners start playing around with. Of 
course, I am not actually proposing this, but this is in the same spirit.

>
> My question here is whether it is really intended that all matrices get 
> stuck with these (almost) senseless methods? 
>

Yes, and because they are there, I can do things like easily construct an 
inverse of a module morphism. (Although there is an issue with the fact 
that the matrices are not immutable that we have to work around.)

>
> (this came up during #23619 where we are introducing "leading_matrix" 
> and "leading_position" for matrices over a univariate polynomial ring.) 
>
> I think you should be more explicit with your method names and call the 
first one leading_term_matrix() and the second one I have no idea why it 
would do.

I entirely agree.  If you had asked me what these methods 
> ('leading_term') etc meant for matrices I would have had absolutely no 
> idea.  But then the same would be true if you had asked me what the 
> "leading term" was of an element of the free module R^n (for any ring 
> R).  So my recommendation would be to get rid of these at that level. 
> They may have meaning for some modules which happen to be free 
> R-modules of finite rank (such as polynomials over R of fixed degree, 
> where they do of course make sense) but not on __all__ R-modules! 
> They have been put in the wrong place.  [In my opinion!] 
>
 
Last time I checked, R^n would be a (finite ranked) free R-module. So I 
don't follow your argument. In fact, these methods make sense for any free 
R-module where there is an (partial) order on the basis. The category 
ModulesWithBasis means objects that are free R-modules. Yet, we don't have 
a good way to check when the basis is indexed by something with a fixed 
partial order, so we just assume that (which is almost always true). So I 
believe they are in the correct place, moreover, I don't see any other 
reasonable place to put these (very useful) methods.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Senseless leading_ methods introduced on all matrices

[Simon King]

Hi Johan,

On 2017-08-18, Johan S. H. Rosenkilde  wrote:
> My question here is whether it is really intended that all matrices get
> stuck with these (almost) senseless methods?

I didn't introduce them, but I believe it would be quite useful for my
applications (provided it is a *fast* method!). Sketch: I am using
Gröbner basis methods for modules over finite dimensional quotients
of path algebras.
"Gröbner basis methods" means that one has all these notions leading_*,
and "finite dimensional" means that elements can be represented by
matrices. By taking a basis that corresponds to the standard monomials
of a Gröbner basis for the quotient relations, the leading_* of matrices
exactly corresponds to the leading_* notion in the sense of Gröbner
bases.

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.