Coercions of polynomials

[Travis Scrimshaw]

Hi everyone,

   I wanted to know if this is a deliberate behavior or a bug:

sage: R.<x,y> = ZZ[]
sage: S.<a,b> = R[]
sage: T = ZZ['a,b,x,y']
sage: f = (x+y)*(a+b)
sage: T(f)
...
TypeError: not a constant polynomial

I understand that there should not be a coercion from S to T, but I feel like we should be able to have conversions (anytime the variables of S are a subset of those of T). I have a vague recollection that this used to work, but I wouldn't know the last version I tried to do this. What do you think?

Thanks,

Travis

[Vincent Delecroix]

Maybe you want

sage: T(S.flattening_morphism()(f))
a*x + b*x + a*y + b*y

[David Roe]

I agree that T(f) should work.

David

 

>
> Thanks,
> 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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d8edc2b6-4732-f523-ba1c-71001a3aac99%40gmail.com.

[Travis Scrimshaw]

So one thing I thought of that could be a problem is this:

ZZ['x'] --> ZZ['x,y']['x']

or more generally anytime there are repeated variable names. Actually, in this case, I feel the default should be to go into the base ring rather than the final ring, but another option would be to just error out and say it is ambiguous.

Best,

Travis

To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

[David Roe]

On Tue, Jan 14, 2020 at 11:32 AM Travis Scrimshaw <tsc...@ucdavis.edu> wrote:

So one thing I thought of that could be a problem is this:

ZZ['x'] --> ZZ['x,y']['x']

or more generally anytime there are repeated variable names. Actually, in this case, I feel the default should be to go into the base ring rather than the final ring, but another option would be to just error out and say it is ambiguous.

I think an error is best.  Users can always use lists if they really want to do something like this.

David

 

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/fbb0a228-daaa-4b67-9aef-368005972c1c%40googlegroups.com.

[Marc Mezzarobba]

[re-posting a reply from a week ago that apparently did not go through
because of the gmane move]

David Roe wrote:
>> So one thing I thought of that could be a problem is this:
>>
>> ZZ['x'] --> ZZ['x,y']['x']
>>
>> or more generally anytime there are repeated variable names.
>> Actually, in this case, I feel the default should be to go into the
>> base ring rather than the final ring, but another option would be to
>> just error out and say it is ambiguous.
>
> I think an error is best. Users can always use lists if they really
> want to do something like this.

Since we have no real mechanism for creating fresh indeterminates,
raising and error here would really complicate code written for
univariate polynomial rings over generic base rings.

--
Marc

[Nils Bruin]

On Wednesday, January 22, 2020 at 5:11:16 AM UTC-8, Marc Mezzarobba wrote:

David Roe wrote:
>> So one thing I thought of that could be a problem is this:
>>
>> ZZ['x'] --> ZZ['x,y']['x']
>>

[...]

 

>
> I think an error is best.  Users can always use lists if they really
> want to do something like this.

Since we have no real mechanism for creating fresh indeterminates,
raising and error here would really complicate code written for
univariate polynomial rings over generic base rings.

I think the only choice (if any) is to match the occurrence of a name in the smallest ring.

If your generic code is relying on coercion in a setting where name matching like this is relevant, I suspect it's almost certainly the wrong choice. Code of any generality should probably not rely on such coercions and use explicit homomorphisms instead.

An error would probably be annoying because it would only get triggered in rare settings, but an error would be better than the system silently making an unexpected choice.

[Marc Mezzarobba]

Nils Bruin wrote:
> I think the only choice (if any) is to match the occurrence of a name
> in the smallest ring.
>
> If your generic code is relying on coercion in a setting where name
> matching like this is relevant, I suspect it's almost certainly the
> wrong choice.

I think we agree. To clarify, what I was trying to say is that

(1) Forbidding polynomial ring towers with repeated variables breaks
essentially all code that creates polynomial rings for its private use
over base rings provided by the caller, even code that doesn't use
coercion, say

def foo(a):
Pol = PolynomialRing(a.parent(), 'x')
return Pol([a, 1]).roots()

(Everyone in this thread probably agrees on that part.)

(2) Disallowing conversions from R to R[x] when R already contains a
variable called x doesn't sound great to me either. Indeed, converting
constants into polynomials is a pretty common operation, it is quite
idiomatic to use parent-call syntax for that, and it may not be obvious
on first sight that it could fail in some cases. Whereas I can only
think of rather contrived examples where one would write Pol(p) in a
situation where ambiguity may occur and expect it to map the variable of
the polynomial p to that of the ring Pol. (Not only the pitfall is more
evident, but also there are often other natural tools to do the job,
e.g. change_ring() methods.)

--
Marc