Re: [sage-combinat-devel] Re: Category Questions
Nicolas M. Thiery wrote: > Strange, I just moved them all the way up the Sage-Combinat queue, and > it seems to commute fine with the rest. Could you try again with the > patches from the queue, and if that's the issue maybe reexport to > trac? Arg. This is my fault. Apparently, I never pushed my latest patch to the combinat server; only to trac. Which means I have to look somewhat carefully to see if there is anything useful in my later patch which you did not duplicate. I'll try to do this within the next day or so. Cheers, Jason > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Thu, Feb 18, 2010 at 01:17:43PM -0500, Jason Bandlow wrote: > Hi Nicolas, > > Nicolas M. Thiery wrote: > > It would be good to have this patch finalized for next week. I am > > going to upload my review patch on trac. Any chances for you to review > > it soon? And then it will just remain to take a final decision for > > what upper/lower triangular is. > > I just tried applying > > trac_7914_triangular_morphisms-jb.patch > trac_7914_triangular_morphisms-review-nt.patch > > to a clean 4.3.2, and got rejections. I don't have a lot of time today, > but tomorrow I will try to sort this out (if you haven't already) and > give this a final review. Strange, I just moved them all the way up the Sage-Combinat queue, and it seems to commute fine with the rest. Could you try again with the patches from the queue, and if that's the issue maybe reexport to trac? Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Hi Nicolas, Nicolas M. Thiery wrote: > It would be good to have this patch finalized for next week. I am > going to upload my review patch on trac. Any chances for you to review > it soon? And then it will just remain to take a final decision for > what upper/lower triangular is. I just tried applying trac_7914_triangular_morphisms-jb.patch trac_7914_triangular_morphisms-review-nt.patch to a clean 4.3.2, and got rejections. I don't have a lot of time today, but tomorrow I will try to sort this out (if you haven't already) and give this a final review. Cheers, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Hi Jason, Hmm, we did not get much feedback on that one. Altogether, I am definitely positive on the def of leading term. But only have a medium preference for upper/lower. It would be good to have this patch finalized for next week. I am going to upload my review patch on trac. Any chances for you to review it soon? And then it will just remain to take a final decision for what upper/lower triangular is. Cheers, Nicolas On Thu, Feb 11, 2010 at 01:21:18AM +0100, Nicolas M. Thiery wrote: > On Wed, Feb 10, 2010 at 11:10:46AM -0500, Jason Bandlow wrote: > > I am indifferent to the choice of convention. I agree that the conflict > > you point out is disturbing. My choice for using the smallest support > > was based on the current behavior of printing in sage (for most > > combinatorics). > > > > sage: X = CombinatorialFreeModule(QQ, [1,2,3]); B = X.basis() > > sage: B[3] + B[1] > > B[1] + B[3] > > > > sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() > > sage: s(e[1]^3) > > s[1, 1, 1] + 2*s[2, 1] + s[3] > > > > I vote -1 on leading_term always giving the last term printed and > > trailing_term always giving the first term printed. I have no problem > > with changing the order of printing, though. > > Ah, interesting. As Simon, I really have a Gröbner point of view here > (leading = large). I had actually never associated the leading term of > something with how it reads on screen. Probably because the printing > convention varies from system to system, and even within a system. > > For polynomials, the terms are sorted decreasingly, so it would be > consistent to do the same for symmetric functions and the like > (although series are probably printed the other way around). I am just > a bit reluctant to fix all the doctests accordingly, but sage > -fixdoctest can probably relieve us from most of the trouble. > > Preference anyone? In particular, who thinks consistency between > leading / trailing and the way elements are printed is important? > > > > A related call for votes: what do we want to mean by upper/lower > > > triangular morphisms? Let X be a module with basis, and b its basis. > > > > > > Then, a morphism f: X->X is upper triangular if, for all i, > > > > > > - Option 1: f( b[i] ) = c * b[i] + smaller terms > > > - Option 2: f( b[i] ) = c * b[i] + larger terms > > > > > > Intuitively, I vote for Option 1. An argument is that this matches > > > with upper triangularity of the matrix A of f when writing the images > > > f(b[i]) as column vectors, which is the usual convention when f(x) is > > > calculated by A * X. > > > > Well, maybe it isn't too unusual to think of x as a row-vector and > > compute f(x) = x * A. > > I know ... I am fairly agnostic as well, and probably are mostly > influenced by the fact that we always teach A*X in class, or at least > here in France. > > Hmm, one point though: morphisms in Sage compose from right to left > (as the usual \circ). So it would be consistent to think left action / > multiplication by their matrix on the left. > > > After all, a list of coefficients looks like a row vector and not a > > column vector. As an example, currently in sage we have > > > > sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() > > sage: s.transition_matrix(m,3) > > [1 1 1] > > [0 1 2] > > [0 0 1] > > > > Do you agree that, in principle, this command should return the matrix > > representing the morphism from the Schur basis to the monomial basis? > > Definitely. > > > If so, this is currently in agreement with option 2, and should be > > changed if we adopt option 1. Again, I am basically agnostic as to the > > convention we choose, as long as we document it and use it consistently. > > Ok. Transition matrix will have to be rewritten in a generic way at > some point anyway, though we will have to be careful with backward > compatibility. > > > I'll note that we seem to be in agreement that the upper-left corner of > > the matrix should be indexed by the (smallest-smallest) pair of indices. > > Yes. > > > I think this is useful, as it naturally generalizes to the commonly > > occurring case of a semi-infinite set with a smallest, but not largest, > > element (eg, NonNegativeIntegers). But I will point out that if we use > > leading_term=largest, then the rows and columns of this matrix will > > begin with the trailing term and end with the leading term, which again > > seems unfortunate to me. > > Yup. > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" > http://Nicolas.Thiery.name/ Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegrou
Re: [sage-combinat-devel] Re: Category Questions
On Wed, Feb 10, 2010 at 11:10:46AM -0500, Jason Bandlow wrote: > I am indifferent to the choice of convention. I agree that the conflict > you point out is disturbing. My choice for using the smallest support > was based on the current behavior of printing in sage (for most > combinatorics). > > sage: X = CombinatorialFreeModule(QQ, [1,2,3]); B = X.basis() > sage: B[3] + B[1] > B[1] + B[3] > > sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() > sage: s(e[1]^3) > s[1, 1, 1] + 2*s[2, 1] + s[3] > > I vote -1 on leading_term always giving the last term printed and > trailing_term always giving the first term printed. I have no problem > with changing the order of printing, though. Ah, interesting. As Simon, I really have a Gröbner point of view here (leading = large). I had actually never associated the leading term of something with how it reads on screen. Probably because the printing convention varies from system to system, and even within a system. For polynomials, the terms are sorted decreasingly, so it would be consistent to do the same for symmetric functions and the like (although series are probably printed the other way around). I am just a bit reluctant to fix all the doctests accordingly, but sage -fixdoctest can probably relieve us from most of the trouble. Preference anyone? In particular, who thinks consistency between leading / trailing and the way elements are printed is important? > > A related call for votes: what do we want to mean by upper/lower > > triangular morphisms? Let X be a module with basis, and b its basis. > > > > Then, a morphism f: X->X is upper triangular if, for all i, > > > > - Option 1: f( b[i] ) = c * b[i] + smaller terms > > - Option 2: f( b[i] ) = c * b[i] + larger terms > > > > Intuitively, I vote for Option 1. An argument is that this matches > > with upper triangularity of the matrix A of f when writing the images > > f(b[i]) as column vectors, which is the usual convention when f(x) is > > calculated by A * X. > > Well, maybe it isn't too unusual to think of x as a row-vector and > compute f(x) = x * A. I know ... I am fairly agnostic as well, and probably are mostly influenced by the fact that we always teach A*X in class, or at least here in France. Hmm, one point though: morphisms in Sage compose from right to left (as the usual \circ). So it would be consistent to think left action / multiplication by their matrix on the left. > After all, a list of coefficients looks like a row vector and not a > column vector. As an example, currently in sage we have > > sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() > sage: s.transition_matrix(m,3) > [1 1 1] > [0 1 2] > [0 0 1] > > Do you agree that, in principle, this command should return the matrix > representing the morphism from the Schur basis to the monomial basis? Definitely. > If so, this is currently in agreement with option 2, and should be > changed if we adopt option 1. Again, I am basically agnostic as to the > convention we choose, as long as we document it and use it consistently. Ok. Transition matrix will have to be rewritten in a generic way at some point anyway, though we will have to be careful with backward compatibility. > I'll note that we seem to be in agreement that the upper-left corner of > the matrix should be indexed by the (smallest-smallest) pair of indices. Yes. > I think this is useful, as it naturally generalizes to the commonly > occurring case of a semi-infinite set with a smallest, but not largest, > element (eg, NonNegativeIntegers). But I will point out that if we use > leading_term=largest, then the rows and columns of this matrix will > begin with the trailing term and end with the leading term, which again > seems unfortunate to me. Yup. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Hello Nicolas, Nicolas M. Thiery wrote: > This is a short call for votes about leading terms and triangular > morphisms. > > On Wed, Feb 10, 2010 at 11:06:50AM +0100, Nicolas M. Thiery wrote: >> I finally started to review #7914. One thing that did slip through >> my fingers. I just noticed that leading_term returns the term with >> smallest support. I instead assumed it would return that with >> largest support, as is the case for polynomials: >> >> sage: p = 3*x^2+2*x+1 >> sage: p.leading_coefficient() >> 3 I am indifferent to the choice of convention. I agree that the conflict you point out is disturbing. My choice for using the smallest support was based on the current behavior of printing in sage (for most combinatorics). sage: X = CombinatorialFreeModule(QQ, [1,2,3]); B = X.basis() sage: B[3] + B[1] B[1] + B[3] sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() sage: s(e[1]^3) s[1, 1, 1] + 2*s[2, 1] + s[3] I vote -1 on leading_term always giving the last term printed and trailing_term always giving the first term printed. I have no problem with changing the order of printing, though. > A related call for votes: what do we want to mean by upper/lower > triangular morphisms? Let X be a module with basis, and b its basis. > > Then, a morphism f: X->X is upper triangular if, for all i, > > - Option 1: f( b[i] ) = c * b[i] + smaller terms > - Option 2: f( b[i] ) = c * b[i] + larger terms > > Intuitively, I vote for Option 1. An argument is that this matches > with upper triangularity of the matrix A of f when writing the images > f(b[i]) as column vectors, which is the usual convention when f(x) is > calculated by A * X. Well, maybe it isn't too unusual to think of x as a row-vector and compute f(x) = x * A. After all, a list of coefficients looks like a row vector and not a column vector. As an example, currently in sage we have sage: SF = SymmetricFunctions(QQ); SF.inject_shorthands() sage: s.transition_matrix(m,3) [1 1 1] [0 1 2] [0 0 1] Do you agree that, in principle, this command should return the matrix representing the morphism from the Schur basis to the monomial basis? If so, this is currently in agreement with option 2, and should be changed if we adopt option 1. Again, I am basically agnostic as to the convention we choose, as long as we document it and use it consistently. I'll note that we seem to be in agreement that the upper-left corner of the matrix should be indexed by the (smallest-smallest) pair of indices. I think this is useful, as it naturally generalizes to the commonly occurring case of a semi-infinite set with a smallest, but not largest, element (eg, NonNegativeIntegers). But I will point out that if we use leading_term=largest, then the rows and columns of this matrix will begin with the trailing term and end with the leading term, which again seems unfortunate to me. Best, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
If the variable x has degree 1, I would also tend to say that the leading term is x^2 and Option 1 is preferable. Best, Anne Nicolas M. Thiery wrote: Dear Sage / Sage-combinat devs, This is a short call for votes about leading terms and triangular morphisms. On Wed, Feb 10, 2010 at 11:06:50AM +0100, Nicolas M. Thiery wrote: I finally started to review #7914. One thing that did slip through my fingers. I just noticed that leading_term returns the term with smallest support. I instead assumed it would return that with largest support, as is the case for polynomials: sage: p = 3*x^2+2*x+1 sage: p.leading_coefficient() 3 Florent is also +1 on this convention, and I just fixed the patch accordingly. But it is still time to rollback. Please vote! A related call for votes: what do we want to mean by upper/lower triangular morphisms? Let X be a module with basis, and b its basis. Then, a morphism f: X->X is upper triangular if, for all i, - Option 1: f( b[i] ) = c * b[i] + smaller terms - Option 2: f( b[i] ) = c * b[i] + larger terms Intuitively, I vote for Option 1. An argument is that this matches with upper triangularity of the matrix A of f when writing the images f(b[i]) as column vectors, which is the usual convention when f(x) is calculated by A * X. Please vote! Cheers, Nicolas -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Dear Sage / Sage-combinat devs, This is a short call for votes about leading terms and triangular morphisms. On Wed, Feb 10, 2010 at 11:06:50AM +0100, Nicolas M. Thiery wrote: > I finally started to review #7914. One thing that did slip through > my fingers. I just noticed that leading_term returns the term with > smallest support. I instead assumed it would return that with > largest support, as is the case for polynomials: > > sage: p = 3*x^2+2*x+1 > sage: p.leading_coefficient() > 3 Florent is also +1 on this convention, and I just fixed the patch accordingly. But it is still time to rollback. Please vote! A related call for votes: what do we want to mean by upper/lower triangular morphisms? Let X be a module with basis, and b its basis. Then, a morphism f: X->X is upper triangular if, for all i, - Option 1: f( b[i] ) = c * b[i] + smaller terms - Option 2: f( b[i] ) = c * b[i] + larger terms Intuitively, I vote for Option 1. An argument is that this matches with upper triangularity of the matrix A of f when writing the images f(b[i]) as column vectors, which is the usual convention when f(x) is calculated by A * X. Please vote! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Hi Jason! I finally started to review 7914. One thing that did slip through my fingers. I just noticed that leading_term returns the term with smallest support. I assumed it would return that with largest support: sage: p = 3*x^2+2*x+1 sage: p.leading_coefficient() 3 Do you agree with that? Do you have time to work on this shortly? I have started writing a reviewer's patch in the queue; please have a look at it, and if you get time to work yours, please first merge mine in. Thanks in advance, Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Nicolas M. Thiery wrote:
> On Tue, Jan 26, 2010 at 04:02:17PM -0500, Jason Bandlow wrote:
>> Ok, I tried this, but I'm running into pickling problems with attrcall:
>>
>> sage: f = attrcall("is_one")
>> sage: f == loads(dumps(f))
>> False
>>
>> So I don't know how to implement the approach you suggested and wind up
>> with something that can be pickled in the end. Suggestions?
>
> Oops, I had *completely* forgotten about #5524. I just posted a patch
> which needs review :-)
Thanks! See the ticket for my comments.
-Jason
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Tue, Jan 26, 2010 at 04:02:17PM -0500, Jason Bandlow wrote:
> Ok, I tried this, but I'm running into pickling problems with attrcall:
>
> sage: f = attrcall("is_one")
> sage: f == loads(dumps(f))
> False
>
> So I don't know how to implement the approach you suggested and wind up
> with something that can be pickled in the end. Suggestions?
Oops, I had *completely* forgotten about #5524. I just posted a patch
which needs review :-)
> By the way, thanks for all your help with my tickets lately!
It's my pleasure to see good work being done!
> I am aiming to have 7914 done by the end of the week.
Excellent! I had in my todo list to ask you about its status :-)
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Hi Nicolas,
Jason Bandlow wrote:
> Nicolas M. Thiery wrote:
>
>>Alternative: handle the upper/lower logic once for all in the
>>constructor by defining an attribute self._leading_term set to
>>attrcall("leading_term", cmp) or attrcall("trailing_term", cmp).
>
> Ooh, that sounds nice. Maybe I would call the attribute
> self._dominant_term to avoid the confusion of leading_term meaning
> trailing_term().
Ok, I tried this, but I'm running into pickling problems with attrcall:
sage: f = attrcall("is_one")
sage: f == loads(dumps(f))
False
So I don't know how to implement the approach you suggested and wind up
with something that can be pickled in the end. Suggestions?
By the way, thanks for all your help with my tickets lately! I am
aiming to have 7914 done by the end of the week.
Cheers,
Jason
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Hi Jason! On Tue, Jan 12, 2010 at 10:47:01PM +0100, Nicolas M. Thiery wrote: > > I now have a patch up at > > > > http://trac.sagemath.org/sage_trac/ticket/7914 A couple details; could you: - rename the patch in the queue as on trac - Add a description to the top of the patch (for example using hg qrefresh -e), like: #7914: Implementation of triangular morphisms for modules with basis - extract two functions: def max(iterable, cmp = ...) def min(iterable, cmp = ...) possibly in sage.misc.misc_c, or maybe that should be in the new sage.misc.sage_itertools I introduced in #7921 (but then it will introduce a dependency upon it). Thanks! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Thu, Jan 14, 2010 at 04:04:59PM -0500, Jason Bandlow wrote: > Well, it seems sage-devel approves, so term = coeff * monomial it is. Adjugé, vendu! Thanks for handling this. > I've spent today preparing a patch to do this, and I think I've done it. > I have to run now, but tomorrow I'll put up a trac ticket for you to > look at it. If you want a quick look tonight, it's on the combinat > server. I had a quick look, and this looks good. The next step is to update the patches in the Sage-Combinat queue that are not yet in Sage and use term/monomial. Luckily, there are only a couple of them. For the ncsf one, you can go ahead, and do it in place. For the others, you can either ask permission to the patch author, or do a follow up patch to be folded in later. The last step will be for everyone to update his/her private code if needed. We should advertise this change! > I'll also need to make a good explanation of what I've done to > this list--I'll do that tomorrow too. Thanks! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Hi Nicolas, Nicolas M. Thiery wrote: > For the record: I added in PS a discussion with the MuPAD team in > 1998 ..., about the same issue :-) I would love to see it resolved > once for all. Please make a call on sage-devel, and if there is a > consensus for standardizing for term = coeff * monomial, go ahead with > the change! > > I'd suggest a first patch/ticket doing the change, and then your > triangularity patch on top of it. I am happy to review all of this > promptly. It would be good to have all of this in Sage before Sage > days 20 at the end of February. Well, it seems sage-devel approves, so term = coeff * monomial it is. I've spent today preparing a patch to do this, and I think I've done it. I have to run now, but tomorrow I'll put up a trac ticket for you to look at it. If you want a quick look tonight, it's on the combinat server. I'll also need to make a good explanation of what I've done to this list--I'll do that tomorrow too. Cheers, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Wed, Jan 13, 2010 at 04:47:11PM -0500, Jason Bandlow wrote: > I didn't find this. Oops, there it is! For the record, I added an old file about sf by the way. > But in any case, would it make sense to put it on a wiki somewhere? Until it actually is implemented, yes, sure. > This raises the larger point that I'm still not very clear on an > efficient way to browse the 'Category API'. Suggestions? That's a very good point. And I don't have a good experience in that since I currently know the category code by heart (though I very much hope that this will change soon!). My best suggestion would be: sage: C = ModulesWithBasis(QQ) sage: C.parent_class. sage: C.element_class. But I very much welcome feedback on how this works in practice. Hopefully, Sphinx will eventually be good enough to offer a good synthesis (which in theory is possible; javadoc works well for browsing the rather big hierarchies of Java's library; but there is an extra difficulty here due to the dynamic creation of the hierarchy). > Well, in the 'many monomials' the same monomial could be repeated > multiple times. And why would anyone care about polynomials that > don't have non-negative integer coefficients? :-) I have indeed never seen such a polynomial, except in miscalculations :-) Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ The support of x is the set of all elements of the basis with a non-zero coefficient. A monomial is an element of V with a unique non-zero coefficient. A term is a monomial with coefficient 1. Many methods below only make sense when x has finite support. We will add the following to polylib when they are not already defined properly at the global level. Any better suggestions for support and variations are welcome. F : freeModule x in F s : index F::coeffRing -> F.base_ring F::basis -> F.basis or .basis() F::basisIndices F::basis::keys -> F.basis.keys? # the coefficient of x on the index s coeff(x,s) -> x.coefficient(s) # Associative container operations: nterms(x) : -> len(x) / x.__len__() support(x): -> x.keys() = x.support() // returns a list or a combintorial class (sorted w.r.t the internal order which might or might not be something meaningful depending on the domain) for i in x.support(): ... x[s] = x.coefficient(s) coeff(x, ) : -> x.coefficients() a list of all non-zero coefficients # List of terms and monomials terms(x, )-> x.terms() (or .monomials!!!) monomials(x, )-> x.monomials() (or .terms!!!) poly2list(x):-> __iter__: returns an iterator over pairs [index, coeff] // reverse of MuPAD!!! Order is a term order; can be an identifier or a function BxB->DOM_BOOL support(x, Order): the support of x as a sorted list wrt Order terms(x, Order) : the sorted list of all terms of x wrt Order coeff(x, Order) : the sorted list of all non-zero coefficients wrt Order monomials(x) : the sorted list of all monomials of x wrt Order degreevec/lsupport/monomial2exponent/lexponent ? lsupport(x): The biggest element in the support of x lsupport(x, Order): The biggest element in the support of x w.r.t Order lterm(x):The first term of x lterm(x, Order): ... lmonomial(x): lmonomial(x, Order): ground: constant term -> l.constant_coefficient() reductum(x) in Cat::MonRing should be renamed to lmonomial(x, Rem) x.support[i] // Not essential nthsupport(x,n): the n-th element in the support of x nthmonomial(x,n) : the n-th monomial of x nthterm(x,n) : the n-th term of x nthcoeff(x,n) :the n-th coefficient of x Idem, with Order option content(x):gcd of the numerators/lcm of denominators! (to be made clear in the documentation) primpart(x): x/content(x) : (needs to be made overloadable) mapcoeffs(x,f) : f map elements of R to elements of R; 0->0 applies the function f to every coefficient in x, Maybe add an option which certifies that f will never be zero on a non-zero elements to skip the tests. NoZeroCheck ? mapterms(x, f) : f map a term to a valid term applies the function f to all terms of x multcoeffs(x,c): scalar multiplication For non-commutative base rings, should this be left or right multiplication ? See also: smult(lambda, x) in Dom::FreeModule degree(x): we assume that the basis as some degree method returns the maximal degree in the support of x degreevec(x): we assume that the basis as some degree method returns the maximal degree in the suppor
[sage-combinat-devel] Re: Category Questions
Hi Nicolas, > Please see the attached document I had written with Mike when he > implemented CombinatorialFreeModule (and that I should have > advertised). It contains a (preliminary/to be cleaned up) list of > standard ModulesWithBasis methods. I didn't find this. But in any case, would it make sense to put it on a wiki somewhere? This raises the larger point that I'm still not very clear on an efficient way to browse the 'Category API'. Suggestions? > See also: > > http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/ModulesWithBasis.mu?view=markup > http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/DOC/ModuleWithBasis.mupdoc?view=markup > http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/TEST/ModuleWithBasis.tst?view=markup Thanks! > For the record: I added in PS a discussion with the MuPAD team in > 1998 ..., about the same issue :-) I would love to see it resolved > once for all. Please make a call on sage-devel, and if there is a > consensus for standardizing for term = coeff * monomial, go ahead with > the change! Done. We'll see what people say. > I'd suggest a first patch/ticket doing the change, and then your > triangularity patch on top of it. I am happy to review all of this > promptly. It would be good to have all of this in Sage before Sage > days 20 at the end of February. OK. That seems possible. > In the lectures I heard, the same convention was used as in MuPAD, > and Becker/Weispfennig, "Groebner bases" agrees with this convention. > From the etymological viewpoint, this sounds logical because poly nomoi > is plural of (ho) monos nomos, so if a monomial was defined by having > coefficient 1, then in a polynomial (= "many (mon)nomials"), all > coefficients > would have to equal 1, too. Maybe you start a discussion in sci.math ? :-) Well, in the 'many monomials' the same monomial could be repeated multiple times. And why would anyone care about polynomials that don't have non-negative integer coefficients? :-) Cheers, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Hi Jason, On Tue, Jan 12, 2010 at 06:05:06PM -0500, Jason Bandlow wrote: > > - self._monomial_coefficients is specific to the > >CombinatorialFreeModule implementation. But you can use directly > >x[k] to get the coefficient of k in an element x of a module with > >basis. > > Very good to know. Do you know how I can get the list of all basis > elements which appear in x? Will x.support() work? Yes! The standard ModulesWithBasis methods ought to be listed and documented in the category, either as abstract_methods or as default implementations. Please see the attached document I had written with Mike when he implemented CombinatorialFreeModule (and that I should have advertised). It contains a (preliminary/to be cleaned up) list of standard ModulesWithBasis methods. See also: http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/ModulesWithBasis.mu?view=markup http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/DOC/ModuleWithBasis.mupdoc?view=markup http://mupad-combinat.svn.sourceforge.net/viewvc/mupad-combinat/trunk/MuPAD-Combinat/lib/DOMAINS/CATEGORY/TEST/ModuleWithBasis.tst?view=markup > >By the way, at some point, we should have an > >ModulesWithBasis(...).example(), with a very minimal implementation > >to catch this kind of things in tests. > > Agreed. I'll try to create this too. (It will be another good way for > me to learn more about Categories). Cool, thanks! You can have a look in ModulesWithBasis.tst above for a (too minimal) example; it just had to implement fromList (replaced by from_dict in Sage), toList (replaced by __iter__ in Sage), coeff, and monomial. For Sage's minimal example, I'd suggest KK^n (where KK is the base_ring of the module with basis, and n defaults to, say, 4), with elements represented as lists of n elements of KK. > >Now, we hit the question of what a term is, and what a monomial is. > >We currently use MuPAD's convention that x^3 is a term, while 2*x^3 > >is a monomial. But other system use the reverse convention. > > I think Sage already has the reverse convention. If f=2*x^3*y^2 in a > MultiPolynomialRing, f.lc() currently returns 2 and f.lm() currently > returns x^3*y^2. The SymbolicRing seems to have methods > leading_coefficient() and trailing_coefficient(), along with > not-very-shortcuts leading/trailing_coeff(), which take a single > variable as input and return everything which is multiplied by that > variable in the first term in which that variable appears. A > UnivariatePolynomialRing seems to have leading_coefficient() but nothing > else. I had looked at these before, but your comment prompted me to > look further. I found this in the doc of > sage.rings.polynomial.toy_d_basis (written by Martin Albrecht): > >The notion of 'term' and 'monomial' in [BW93]_ is swapped from the >notion of those words in Sage (or the other way around, however you >prefer it). In Sage a term is a monomial multiplied by a >coefficient, while in [BW93]_ a monomial is a term multiplied by a >coefficient. Also, what is called LM (the leading monomial) in >Sage is called HT (the head term) in [BW93]_. > > So, as I understand it, > > 3 * x^2 : term > 3 : coefficient > x^2 : monomial > > would be consistent with the rest of Sage. Do you know of someplace in > Sage that is not consistent with that? Not on top of my head. But a systematic search is in order. It would be worthwhile to include embedded software in the search. Singular and Magma seem to use the same convention as Sage (term = c * monomial): http://www.singular.uni-kl.de/Manual/3-1-0/sing_231.htm#SEC272 http://magma.maths.usyd.edu.au/magma/htmlhelp/text313.htm#1968 > >It's kind of the last occasion we have to change that; it might > >actually be too late. Still, could you raise the issue on sage-devel? > > Do you still think so? Thinking twice about it, the change should not be that bad, since term is current essentially monomial with a default second argument coeff=1; so we can swap the two while maintaining backward compatibility. The other functions that should be fixed as well (sum_of_terms/sum_of_monomials, ...) are not that many, and I don't expect them to have been used much outside of our patches. > If you do, and if you can answer my previous question, I am happy to > do this. Great, thanks! For the record: I added in PS a discussion with the MuPAD team in ... 1998 ..., about the same issue :-) I would love to see it resolved once for all. Please make a call on sage-devel, and if there is a consensus for standardizing for term = coeff * monomial, go ahead with the change! I'd suggest a first patch/ticket doing the change, and then your triangularity patch on top of it. I am happy to review all of this promptly. It would be good to have all of this in Sage before Sage days 20 at the end o
Re: [sage-combinat-devel] Re: Category Questions
Thanks for your comments Nicolas! Some of my thoughts...
Nicolas M. Thiery wrote:
> - self._monomial_coefficients is specific to the
>CombinatorialFreeModule implementation. But you can use directly
>x[k] to get the coefficient of k in an element x of a module with
>basis.
Very good to know. Do you know how I can get the list of all basis
elements which appear in x? Will x.support() work?
>By the way, at some point, we should have an
>ModulesWithBasis(...).example(), with a very minimal implementation
>to catch this kind of things in tests.
Agreed. I'll try to create this too. (It will be another good way for
me to learn more about Categories).
> - trailing_term could possibly be implemented in terms of leading_term(...,
> -cmp)
>(well, -cmp is not valid python but you see the idea)
You're right. I got lazy with copy/paste but the logic should have a
single home. I'll fix.
>Now, we hit the question of what a term is, and what a monomial is.
>We currently use MuPAD's convention that x^3 is a term, while 2*x^3
>is a monomial. But other system use the reverse convention.
I think Sage already has the reverse convention. If f=2*x^3*y^2 in a
MultiPolynomialRing, f.lc() currently returns 2 and f.lm() currently
returns x^3*y^2. The SymbolicRing seems to have methods
leading_coefficient() and trailing_coefficient(), along with
not-very-shortcuts leading/trailing_coeff(), which take a single
variable as input and return everything which is multiplied by that
variable in the first term in which that variable appears. A
UnivariatePolynomialRing seems to have leading_coefficient() but nothing
else. I had looked at these before, but your comment prompted me to
look further. I found this in the doc of
sage.rings.polynomial.toy_d_basis (written by Martin Albrecht):
The notion of 'term' and 'monomial' in [BW93]_ is swapped from the
notion of those words in Sage (or the other way around, however you
prefer it). In Sage a term is a monomial multiplied by a
coefficient, while in [BW93]_ a monomial is a term multiplied by a
coefficient. Also, what is called LM (the leading monomial) in
Sage is called HT (the head term) in [BW93]_.
So, as I understand it,
3 * x^2 : term
3 : coefficient
x^2 : monomial
would be consistent with the rest of Sage. Do you know of someplace in
Sage that is not consistent with that?
>It's kind of the last occasion we have to change that; it might
>actually be too late. Still, could you raise the issue on sage-devel?
Do you still think so? If you do, and if you can answer my previous
question, I am happy to do this.
>It seems a waste to create a monomial as an element of the free
>module just to extract right after the support and coeff. Any idea
>on a good name for leading_blurb that would just return a pair?
>
>maybe x.leading_item, consistent with items/iteritems/... of dictionaries?
You're right. Maybe x._leading_item or x._leading_mc ? Or do you think
this should also be exposed? More generally, which of the eight methods
(leading/trailing_coeff/monomial/term/items) should or should not be public?
>Alternative: handle the upper/lower logic once for all in the
>constructor by defining an attribute self._leading_term set to
>attrcall("leading_term", cmp) or attrcall("trailing_term", cmp).
Ooh, that sounds nice. Maybe I would call the attribute
self._dominant_term to avoid the confusion of leading_term meaning
trailing_term().
I know I haven't responded to all your points here, but now it's time
for dinner. :) Thanks again for your help.
Cheers,
Jason
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Tue, Jan 12, 2010 at 03:58:32PM -0500, Jason Bandlow wrote:
> > phi is constructed from f, which itself can't be pickled:
> Thanks for your help on this!
My pleasure :-)
> I now have a patch up at
>
> http://trac.sagemath.org/sage_trac/ticket/7914
>
> in case you want to see if I understood you. :)
Cl! I'll look at this in detail soon.
In the mean time, here are a couple thoughts. Sorry, it would have
been best to raise them before your cleanup, but they came up while
browsing through the patch ...
- do we want leading_term or lterm (less explicit, but used in most
systems)? You might want to raise that on sage-devel.
- self._monomial_coefficients is specific to the
CombinatorialFreeModule implementation. But you can use directly
x[k] to get the coefficient of k in an element x of a module with
basis.
By the way, at some point, we should have an
ModulesWithBasis(...).example(), with a very minimal implementation
to catch this kind of things in tests.
- trailing_term could possibly be implemented in terms of leading_term(...,
-cmp)
(well, -cmp is not valid python but you see the idea)
- trailing_term should return a term
Now, we hit the question of what a term is, and what a monomial is.
We currently use MuPAD's convention that x^3 is a term, while 2*x^3
is a monomial. But other system use the reverse convention.
It's kind of the last occasion we have to change that; it might
actually be too late. Still, could you raise the issue on sage-devel?
- a typical use case is:
(support, coeff) = x.leading_blurb()
It seems a waste to create a monomial as an element of the free
module just to extract right after the support and coeff. Any idea
on a good name for leading_blurb that would just return a pair?
maybe x.leading_item, consistent with items/iteritems/... of dictionaries?
Then, the other methods could be implemented in term of that low
level function.
- Suggestion: given how it is used, use an attribute self._upper set
to True/False, rather than self.triangularity set to upper/lower.
Alternative: handle the upper/lower logic once for all in the
constructor by defining an attribute self._leading_term set to
attrcall("leading_term", cmp) or attrcall("trailing_term", cmp).
- move most of the code of _invert_on_basis into a public method
self.preimage(x), and let _invert_on_basis(i) call
self.preimage(codomain.term(i))
This will open the door for later generalization to non injective
triangular morphism, and partial preimages.
- rename the private _invert_on_basis into a public method preimage
Thanks much!
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Hi Nicolas, Nicolas M. Thiery wrote: > phi is constructed from f, which itself can't be pickled: Thanks for your help on this! I now have a patch up at http://trac.sagemath.org/sage_trac/ticket/7914 in case you want to see if I understood you. :) Cheers, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
Hi Jason!
On Tue, Jan 12, 2010 at 12:19:36PM -0500, Jason Bandlow wrote:
> While working on this, I added a ``TestSuite(phi)`` test where ``phi``
> is a TriangularModuleMorphism, mimicking what was done for
> DiagonalModuleMorphism.
Good idea!
> Unfortunately, pickling fails. I don't really know where to start
> tracking this down... can you give me a pointer?
phi is constructed from f, which itself can't be pickled:
sage: X = CombinatorialFreeModule(QQ, [1, 2, 3]); X.rename("X")
sage: Y = CombinatorialFreeModule(QQ, [1, 2, 3]); y = Y.basis()
sage: f = lambda i: sum( y[j] for j in range(i,4) )
sage: loads(dumps(f))
Traceback (most recent call last):
PicklingError: Can't pickle : attribute lookup
__builtin__.function failed
That's because functions are pickled by name; but the name of f is
__main__.f. Pickles detects that there is no such function in the
__main__module, and rightfully deduces that f could not be unpickled
in a latter Sage session.
Luckily, one can cheat-around this, faking f being picklable, by
forcefully inserting it into __main__, as in:
sage: import __main__; __main__.f = f
Oh, and f should be defined with def, not lambda.
sage: X = CombinatorialFreeModule(QQ, [1, 2, 3]); X.rename("X")
sage: Y = CombinatorialFreeModule(QQ, [1, 2, 3]); y = Y.basis()
sage: def f(i): sum( y[j] for j in range(i,4) )
sage: import __main__; __main__.f = f
sage: loads(dumps(f))
sage: phi = X.module_morphism(f, triangular=True, codomain = Y)
sage: TestSuite(phi).run()
See the first example of TriangularModuleMorphism.
Altogether, whenever possible, I try to use standard sage functions
(like factorial) for such building blocks in tests. Here is a handy
trick, which involves a bit of magic in sum_of_terms (it's a morphism,
and therefore * is function composition):
sage: f = Y.sum_of_terms * range
sage: f(5)
B[0] + B[1] + B[2] + B[3] + B[4]
sage: loads(dumps(f))
A map to X
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil"
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Nicolas M. Thiery wrote: > Hey Jason, > In fact, I was about to send you an e-mail for two things :-) > > - Warn you about the rebase + little fixes in >triangular-morphisms-jb.patch and ask you about your time-line for >finalizing it. While working on this, I added a ``TestSuite(phi)`` test where ``phi`` is a TriangularModuleMorphism, mimicking what was done for DiagonalModuleMorphism. Unfortunately, pickling fails. I don't really know where to start tracking this down... can you give me a pointer? The patch with the problematic test is on the sage-combinat server (triangular-morphisms-jb.patch). The test that fails is on line 730 of sage.categories.modules_with_basis.py Thanks for any help! -Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Re: Category Questions
On Thu, Jan 07, 2010 at 12:10:11PM -0500, Jason Bandlow wrote: > Apologies if this ends up as a double-post... my first attempt to > respond seems to have vanished. I only got one. So everything is good for us. > I'll take a look at this soon. If there are no more dependency > problems, it should be easy to finalize and post a ticket. Cool! > I have a question, but I'll take that discussion to the ticket comments. Thanks! I just cleaned up the patch, and I'll post it once I am back online. > OK, I'm beginning to see the light. Data structure information in > the superclass, mathematical information in the category. Good. Exactly. > I think part of what was confusing me was the mix of generic and > ncsf specific code in categories.py. I first saw the very generic > code there, and it felt wrong to have much more specific code in the > same place, so I wanted to move it to the Basis class. Ok. > Now, assuming the concrete representation stuff gets factored out, would > you suggest one file or two for qsym? I.e., should there be qsym.py and > qsym_categories.py, or is one file OK? Do you have any general style > recommendations for this kind of thing? I would definitely suggest one directory for qsym (as for sf/ncsf): it's likely to evolve in something quite big. Then, maybe: qsym/qsym.py# the abstract QSym algebra qsym/categories.py # the categories qsym/classical.py # the classical bases And eventually: qsym/hall_littlewood.py # other bases, grouped by theme qsym/... At some point, we might want to also split the classical.py file if the code for some of the bases become large. But anyway, since there will be a single entry point (namely sage.combinat.qsym.QuasiSymmetricFunctions), we can later freely move everything else around without breaking imports, so it's not critical. That being said, please listen to the code, and if some different layout feels more natural, let me know! Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Category Questions
Apologies if this ends up as a double-post... my first attempt to respond seems to have vanished. Nicolas M. Thiery wrote: >> Hey Jason, >> >> It's good to hear from you. Happy new year! Happy new year! >> In fact, I was about to send you an e-mail for two things :-) >> >> - Warn you about the rebase + little fixes in >> triangular-morphisms-jb.patch and ask you about your time-line for >> finalizing it. I'll take a look at this soon. If there are no more dependency problems, it should be easy to finalize and post a ticket. >> - Ask whether you could review #, since it's a fun number, and >> you are a major supporter of this feature. I have a question, but I'll take that discussion to the ticket comments. >> (dangerous to mail me isn't it? :-) ) :) Is there a reason they aren't in sage-main? Can we put them in somewhere? >> Yes, they definitely should be with the other categories. Florent >> will be home today, and I'll discuss this with him, and get back to >> you. >> >> For the moment, just use the copies. Great, keep me posted. 'ParentMethods' feels like sneaking code in through the back door, and while I accept that it may sometimes be necessary, I think I would like to personally avoid it, if I can. Can I? :) >> It's not sneaking code in behind the door, it's the goal! - On one >> hand, what is really tied to the particular data structure; e.g. >> that we are inheriting from CombinatorialFreeModule. That goes in >> the common super class Basis. >> >> - One the other hand everything that is abstract. That goes in the >> category Bases(QSym) (or subcategories). >> >> As usual, the more abstract stuff we put in the category the >> better. In theory, we could almost get rid of Basis. Most of the >> things that are currently there are workarounds because category >> code can't override methods implemented in Parent (like _repr_). >> Those methods should really be moved from Parent into Sets(), but >> that will have to wait a bit until all Sage's parents use >> categories. OK, I'm beginning to see the light. Data structure information in the superclass, mathematical information in the category. Good. I think part of what was confusing me was the mix of generic and ncsf specific code in categories.py. I first saw the very generic code there, and it felt wrong to have much more specific code in the same place, so I wanted to move it to the Basis class. Now, assuming the concrete representation stuff gets factored out, would you suggest one file or two for qsym? I.e., should there be qsym.py and qsym_categories.py, or is one file OK? Do you have any general style recommendations for this kind of thing? Cheers, Jason -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
