Re: [sage-combinat-devel] Re: map_coefficients factor
On Tue, Apr 21, 2015 at 11:44:02AM -0700, 'Martin R' via sage-combinat-devel wrote: >I just pushed an initial try. If you care, could you have a look >whether it's in principle OK? Thanks for taking action! I just commented on it on the ticket [1]. Please anyone interested by `.map_coefficients(f, check=True)` have a look at the ticket and let's continue the discussion there. Nicolas [1] http://trac.sagemath.org/ticket/18264 -- 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 unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: map_coefficients factor
I just pushed an initial try. If you care, could you have a look whether it's in principle OK? Thanks, Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: map_coefficients factor
I opened a ticket: http://trac.sagemath.org/ticket/18264 Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: map_coefficients factor
On Sat, Apr 18, 2015 at 12:10:47PM -0700, 'Martin R' via sage-combinat-devel wrote: >Sorry, I should have made myself clearer: I do not understand the >design decision behind the way map_coefficients works. >Shouldn't it rather check whether the function actually produces >something in the coefficient ring? That's the usual speed vs safety vs flexibility. We definitely want to have a fast map_coefficients that does no check, for those cases where we know that f is an endofunction as specified by the documentation. In some cases the user can find it handy to abuse the system a bit (like Mike is doing), just for output. In all other cases it would be preferable to have systematic checks. Supporting both speed vs safety boils down to adding an option `check=True`, and if possible going trough the Sage code and setting `check=False` wherever we know we are on the safe side. It's an easy change. Volunteers welcome! For supporting cleanly Mike's needs for flexibility, we really would need to change the base ring. It would be nice to have some idiom like: sage: f.map_coefficients(factor, codomain=SR) or sage: f.change_base_ring(SR).map_coefficients(factor) This one is a bit trickier. 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 unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: map_coefficients factor
> .map_coefficients doesn't produce an element of the same parent in this case (here it is returning a malformed Sage object). In this example it is sending a symmetric function with coefficients in the ring QQ to a symmetric function with coefficients that are factor objects. It however is not aware that the object that it is producing is not valid. What is going "wrong" is that it is throwing away empty factors (or in this case factor(1) or even factor(-1)). Technically this is also not wrong either because you want empty factors to be 'False' for other applications. Sorry, I should have made myself clearer: I do not understand the design decision behind the way map_coefficients works. Shouldn't it rather check whether the function actually produces something in the coefficient ring? Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: map_coefficients factor
.map_coefficients doesn't produce an element of the same parent in this case (here it is returning a malformed Sage object). In this example it is sending a symmetric function with coefficients in the ring QQ to a symmetric function with coefficients that are factor objects. It however is not aware that the object that it is producing is not valid. What is going "wrong" is that it is throwing away empty factors (or in this case factor(1) or even factor(-1)). Technically this is also not wrong either because you want empty factors to be 'False' for other applications. -Mike On Saturday, 18 April 2015 14:33:08 UTC-4, Martin R wrote: > > I'm surprised that map_coefficients insists on producing an element of the > same parent. Why is this reasonable? > > Martin > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-combinat-devel] Re: map_coefficients factor
On Sat, Apr 18, 2015 at 7:04 AM, Mike Zabrocki wrote: > Let me give you another example of how I think Sage is not good at being a > CAS: > sage: (q,t)=QQ['q','t'].fraction_field().gens() > sage: a = (-q^5)/(-t^3) > sage: expand(a) > (-q^5)/(-t^3) > sage: simplify(a) > (-q^5)/(-t^3) > > How do I get Sage to realize the output is not "right"? > This is #15470 ( http://trac.sagemath.org/ticket/15470 ). I must say I understand the logic behind it -- cancelling polynomials should not require cancelling elements of their base ring, as the latter might be impossible or not implemented --, but I would be happy to see a function which "deep cancels" a fraction. -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: map_coefficients factor
I'm surprised that map_coefficients insists on producing an element of the same parent. Why is this reasonable? Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: map_coefficients factor
I'm not looking for a workaround. I know it happens. I can watch out for it. I am really hoping that there is an improvement to make Sage behave better. Sage should be a good Computer Algebra System, but for examples like this it really pretty poor. Moreover, I am sure that other users will run into this same example and perhaps not notice that the coefficients 1 are disappearing (because in the case I first ran into it, the output was pages long). Let me give you another example of how I think Sage is not good at being a CAS: sage: (q,t)=QQ['q','t'].fraction_field().gens() sage: a = (-q^5)/(-t^3) sage: expand(a) (-q^5)/(-t^3) sage: simplify(a) (-q^5)/(-t^3) How do I get Sage to realize the output is not "right"? There is correct output and there is output which is helpful. Sage does the former very well, I think that there should be some effort put in the latter. -Mike On Friday, 17 April 2015 17:36:23 UTC-4, Travis Scrimshaw wrote: > > Hey Mike, >At least as a workaround you could do something like this: > > sage: s=SymmetricFunctions(QQ).s() > sage: x = s[2,1] + 2*s[3] > sage: for i,c in x: print i, factor(c) > [3] 2 > [2, 1] 1 > > Best, > Travis > > > On Wednesday, April 15, 2015 at 5:00:18 PM UTC-4, Mike Zabrocki wrote: >> >> Hi all, >> There is very strange behavior if you want factored coefficients of a >> free module. Let me give an example in the ring of symmetric functions: >> >> sage: s=SymmetricFunctions(QQ).s() >> sage: (s[2,1] + 2*s[3]).map_coefficients(factor) >> 2*s[3] >> >> What is happening here is that 'factor' returns a factorization object. >> factor(1) is an empty list and hence is 'false'. Now if you look at the >> code for 's._from_dict' it removes objects which are empty. >> >> If you look at the documentation for 'map_coefficients' you can see that >> this is not technically a bug because map_coefficients needs to be an >> endofunction on the coefficient ring. In this case, factor is mapping from >> QQ to factor objects and so I wouldn't want to play with the result of that >> command. On the other hand, in symmetric functions (especially with >> multiple parameters like Macdonald or Hall-Littlewood) one would frequently >> like to factor coefficients to know that the coefficients have a nice form. >> >> Does anyone have any suggestions about what should happen with this case? >> I was discussing it with a few people, but we ruled out changing >> factor, map_coefficients or _from_dict. >> >> I find that to work with coefficients in a polynomial ring, the functions >> factor, simplify, expand are unsatisfactory because the output is rarely in >> a form that shows me what I want to see (Maple and Mathematica seem better >> at this). Perhaps what I would like to have is a function 'niceify' that >> displays a coefficient in a pretty form. >> > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-combinat-devel] Re: map_coefficients factor
Hey Mike, At least as a workaround you could do something like this: sage: s=SymmetricFunctions(QQ).s() sage: x = s[2,1] + 2*s[3] sage: for i,c in x: print i, factor(c) [3] 2 [2, 1] 1 Best, Travis On Wednesday, April 15, 2015 at 5:00:18 PM UTC-4, Mike Zabrocki wrote: > > Hi all, > There is very strange behavior if you want factored coefficients of a free > module. Let me give an example in the ring of symmetric functions: > > sage: s=SymmetricFunctions(QQ).s() > sage: (s[2,1] + 2*s[3]).map_coefficients(factor) > 2*s[3] > > What is happening here is that 'factor' returns a factorization object. > factor(1) is an empty list and hence is 'false'. Now if you look at the > code for 's._from_dict' it removes objects which are empty. > > If you look at the documentation for 'map_coefficients' you can see that > this is not technically a bug because map_coefficients needs to be an > endofunction on the coefficient ring. In this case, factor is mapping from > QQ to factor objects and so I wouldn't want to play with the result of that > command. On the other hand, in symmetric functions (especially with > multiple parameters like Macdonald or Hall-Littlewood) one would frequently > like to factor coefficients to know that the coefficients have a nice form. > > Does anyone have any suggestions about what should happen with this case? > I was discussing it with a few people, but we ruled out changing > factor, map_coefficients or _from_dict. > > I find that to work with coefficients in a polynomial ring, the functions > factor, simplify, expand are unsatisfactory because the output is rarely in > a form that shows me what I want to see (Maple and Mathematica seem better > at this). Perhaps what I would like to have is a function 'niceify' that > displays a coefficient in a pretty form. > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
