[sage-combinat-devel] More LaurentPolynomialRing insanity

[VulK]

Dear all, 
I just noted the following:

sage: R = LaurentPolynomialRing(ZZ,'x,y')
sage: T = R.remove_var('x')
sage: T.inject_variables()
Defining y
sage: y in T
True
sage: y in R
True

As one should expect, now for a second try

sage: R = LaurentPolynomialRing(ZZ,'x,y,z')
sage: T = R.remove_var('x')
sage: T.inject_variables()
Defining y, z
sage: y in T
True
sage: y in R
False

And of course, you try R(y), hell break loose. 

At this point, at least in my experience, there are more issues with
LaurentPolynomialRing than features. Is there any plan to replace the
implementation with something less bug ridden in the near future? 

Should I decide to invest time in rewriting it, would anyone here be
interested to help? Do you have any suggestion/reference on how this should
be done properly?
Thanks
Salvatore

-- 
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] More LaurentPolynomialRing insanity

[VulK]

Thank you for the pointer,
I will move the discussion there.
S.


* Nicolas M. Thiery <nicolas.thi...@u-psud.fr> [2015-11-03 17:04:31]:

> On Tue, Nov 03, 2015 at 04:37:25PM +0100, VulK wrote:
> > I just noted the following:
> > 
> > sage: R = LaurentPolynomialRing(ZZ,'x,y')
> > sage: T = R.remove_var('x')
> > sage: T.inject_variables()
> > Defining y
> > sage: y in T
> > True
> > sage: y in R
> > True
> > 
> > As one should expect, now for a second try
> > 
> > sage: R = LaurentPolynomialRing(ZZ,'x,y,z')
> > sage: T = R.remove_var('x')
> > sage: T.inject_variables()
> > Defining y, z
> > sage: y in T
> > True
> > sage: y in R
> > False
> > 
> > And of course, you try R(y), hell break loose. 
> > 
> > At this point, at least in my experience, there are more issues with
> > LaurentPolynomialRing than features. Is there any plan to replace the
> > implementation with something less bug ridden in the near future? 
> > 
> > Should I decide to invest time in rewriting it, would anyone here be
> > interested to help? Do you have any suggestion/reference on how this should
> > be done properly?
> 
> Just a note: this would be better discussed on sage-devel.
> 
> Cheers,
>   Nicolas
> --
> Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
> 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.

-- 
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] Fast polynomial powers

[VulK]

Dear all,
As some of you might know I am trying to optimize the way in which cluster
algebras are implemented in sage. 

In my current implementation one of the biggest bottleneck happens when 
I take powers of polynomials in n variables (n is usually much smaller than
10) with integer coefficients and quite high degrees (few hundreds). 
The way I am computing things now is, probably, the dumbest possible:

sage: f in PolynomialRing(ZZ,'u0,u1,u2')
True
sage: f.degree()
159
sage: len(f.monomials())
18105
sage: %time foo = f**2
CPU times: user 4min 30s, sys: 5 ms, total: 4min 30s
Wall time: 4min 30

Is there some clever way to save some time here or it is just hopeless?
Thanks
S.




-- 
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: Fraction field elements are not simplified

[VulK]

Dear All,
here is a brief status update on this issue. TL;DR: Laurent Polynomial Ring
does not provide a gcd implementation.

Recall that we are in this situation:
sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'),'x')
sage: R = L.fraction_field()
sage: R.inject_variables()
Defining x
sage: x.gcd(x)
1

This is the implementation of gcd called by x.gcd(x)

@coerce_binop
def gcd(self, other):
P = self.parent()
try:
selfN = self.numerator()
selfD = self.denominator()
selfGCD = selfN.gcd(selfD)
otherN = other.numerator()
otherD = other.denominator()
otherGCD = otherN.gcd(otherD)
selfN = selfN // selfGCD
selfD = selfD // selfGCD
otherN = otherN // otherGCD
otherD = otherD // otherGCD
tmp = P(selfN.gcd(otherN))/P(selfD.lcm(otherD))
return tmp
except (AttributeError, NotImplementedError, TypeError, ValueError):
zero = P.zero()
if self == zero and other == zero:
return zero
return P.one()

clearly selfN is x and selfD is 1 as elements of L but

sage: selfN.gcd(selfD) 
...
NotImplementedError: Univariate Laurent Polynomial Ring in t over Integer Ring 
does not provide a gcd implementation for univariate polynomials

S.

PS: of course this is not just a problem with units: 

sage: (x+1).gcd(x+1)
1
sage: (x+1).numerator().gcd(1)
NotImplementedError: Univariate Laurent Polynomial Ring in t over Integer Ring 
does not provide a gcd implementation for univariate polynomials






* Travis Scrimshaw  [2015-10-10 05:57:20]:

>I think I slightly misspoke about the gcd. See the details on
>[1]http://trac.sagemath.org/ticket/16993.
>Best,
>Travis
>On Friday, October 9, 2015 at 4:12:12 PM UTC-5, Travis Scrimshaw wrote:
> 
>Hey Salvatore,
>Â Â  I would say this is the same problem as simplifying scalars of
>fraction fields of polynomials over QQ, that gcd(x, x) = 1 rather than
>x because x is a unit. I don't think we have a way around this
>currently other than doing some kind of explicit coercion.
>Best,
>Travis
>On Friday, October 9, 2015 at 1:40:22 PM UTC-5, Salvatore Stella wrote:
> 
>  Dear all,
>  I just noted the following odd behaviour:
>  sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field()
>  sage: L.inject_variables()
>  Defining x
>  sage: x/x
>  1
>  As one should expect but if we change the base ring then things get
>  messy:
>  sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'),
>  'x').fraction_field()
>  sage: L.inject_variables()
>  Defining x
>  sage: x/x
>  x/x
>  sage: _.denominator()
>  x
>  The fact that x/x is printed out as x/x is still ok if somewhat
>  annoying. But
>  the return value of denominator() is definitely not what I would
>  expect.
>  Is this intentional?
>  Thanks
>  Salvatore
> 
> References
> 
>1. http://trac.sagemath.org/ticket/16993

-- 
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] Fraction field elements are not simplified

[VulK]

Dear all,
I just noted the following odd behaviour:

sage: L = LaurentPolynomialRing(ZZ, 'x').fraction_field()
sage: L.inject_variables()
Defining x
sage: x/x
1

As one should expect but if we change the base ring then things get messy:
sage: L = LaurentPolynomialRing(LaurentPolynomialRing(ZZ,'t'), 
'x').fraction_field()
sage: L.inject_variables()
Defining x
sage: x/x
x/x
sage: _.denominator()
x

The fact that x/x is printed out as x/x is still ok if somewhat annoying. But
the return value of denominator() is definitely not what I would expect.
Is this intentional? 
Thanks
Salvatore

-- 
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] Root systems do not define variables correctly

[VulK]

Hi,
I guess injecting simple roots would be my choice.
If not possible, at least, it would be cleaner to remove inject_variables
from the auto completion list for A.
S.

* Nicolas M. Thiery nicolas.thi...@u-psud.fr [2012-07-12 23:47:34]:

 On Thu, Jul 12, 2012 at 11:08:54PM -0400, VulK wrote:
  I just noticed the following odd behaviour:
  
   sage: L=RootSystem(['A',2]).root_lattice()
   sage: L.inject_variables()
   ---
   ValueErrorTraceback (most recent call 
   last)
   ValueError: variable names have not yet been set using
  
  I am running Sage Version 5.1, Release Date: 2012-07-09 with combinat queue
  both compiled from sources today (I noticed the same behaviour on an old 4.8
  install and I upgraded to check if had already been addressed).
  I assume it will suffices to add _assign_names in the definition of
  root_lattice but I did not have time to check it.
 
 What would you want this method to do for root lattices?
 
   Nicolas
 --
 Nicolas M. Thiéry Isil nthi...@users.sf.net
 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-devel@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.
 

-- 
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-devel@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] Root systems do not define variables correctly

[VulK]

Hi,
I just noticed the following odd behaviour:

 sage: L=RootSystem(['A',2]).root_lattice()
 sage: L.inject_variables()
 ---
 ValueErrorTraceback (most recent call last)
 
 /opt/sage/sage-5.1/ipython console in module()
 
 /opt/sage/sage-5.1/local/lib/python2.7/site-packages/sage/structure/category_object.so
 in sage.structure.category_object.CategoryObject.inject_variables
 (sage/structure/category_object.c:5146)()
 
 /opt/sage/sage-5.1/local/lib/python2.7/site-packages/sage/structure/category_object.so
 in sage.structure.category_object.CategoryObject.variable_names
 (sage/structure/category_object.c:4775)()
 
 ValueError: variable names have not yet been set using
 self._assign_names(...)

I am running Sage Version 5.1, Release Date: 2012-07-09 with combinat queue
both compiled from sources today (I noticed the same behaviour on an old 4.8
install and I upgraded to check if had already been addressed).
I assume it will suffices to add _assign_names in the definition of
root_lattice but I did not have time to check it.
Thanks
Salvatore Stella

-- 
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-devel@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] B-matrix class of finite type cluster algebras

[VulK]

Sorry I meant there are problem applying
trac_6588-categories-root_systems-review-nt.patch
S.

* Christian Stump christian.st...@gmail.com [2012-03-10 18:43:30]:

 Dear Salvatore,
 
         sage: S=ClusterSeed(['E',8])
         sage: T=S.principal_extension()
         sage: T.b_matrix_class()
 
 that was a bug in our code (that was there actually from the beginning
 on). I hope I fixed it; I pushed the changes, could you please recheck
 that you get the right numbers (if that is actually possible!) in some
 small examples like
 
 S=ClusterSeed(X)
 T=S.principal_extension()
 T.b_matrix_class()
 
 for X in types A and B in rank 2 and 3?
 
 Thanks for reporting, Christian
 
 -- 
 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-devel@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.
 

-- 
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-devel@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.