Is this a bug in multipoly _div_?

[Ben Hutz]

The following works

sage: R.<t>=PolynomialRing(QQ)
sage: S.<x>=PolynomialRing(R)
sage: x/S(2)
x/2

The following does not

sage: R.<t>=PolynomialRing(QQ)
sage: S.<x,y>=PolynomialRing(R)
sage: x/S(2)            
Traceback (most recent call last):
...
AttributeError: 'int' object has no attribute 'parent'

Seems to me that if the first one works, then so should the second. I searched the trac server and couldn't come up with anything on this.

Thanks,
  Ben

[Volker Braun]

This is yet another inconsistency with multivariate vs. univariate polynomial rings. They are implemented differently, so its easy to fall into these traps. I don't have any better idea than hope that it gets ironed out over time...

[P Purkayastha]

There is a simple fix for this (I hope).


--- a/sage/rings/polynomial/multi_polynomial_element.py
+++ b/sage/rings/polynomial/multi_polynomial_element.py
@@ -280,7 +280,7 @@
53 bits of precision
"""
if right in self.base_ring():
- inv = 1/self.base_ring()(right)
+ inv = self.base_ring()(1)/self.base_ring()(right)
return inv*self
return self.parent().fraction_field()(self, right, coerce=False)


If it looks right, then I can try and open a ticket.

[P Purkayastha]

Oh. by the way, the command works after applying this ppatch:

sage: sage: R.<t>=PolynomialRing(QQ)
sage: sage: S.<x,y>=PolynomialRing(R)
sage: sage: x/S(2)
1/2*x

[Ben Hutz]

That seems like it fixes the symptoms, but I'm not sure if it is the source of the problem. For example, the following already works without the fix.

sage: R.<s,t>=PolynomialRing(QQ)

sage: S.<x,y>=PolynomialRing(R)
sage: x/S(2)

1/2*x

That being said, I wasn't able to come up with an example that breaks with your change. So with a change this innocuous, I'll review it as a fix of this particular problem.

[Nils Bruin]

On Nov 12, 10:07 am, P Purkayastha <ppu...@gmail.com> wrote:

> +            inv = self.base_ring()(1)/self.base_ring()(right)

It's probably more efficient to do:

inv = self.base_ring().one()/self.base_ring()(right)

since it completely avoids the coercion framework for constructing 1.

[P Purkayastha]

Thanks. I have opened #13704 with this change.

http://trac.sagemath.org/13704