normalize_coordinates for projective morphisms gcd failure

[bhutz]

Is there an existing issue for this?

• I have searched the existing issues for a bug report that matches the one I want to file, without success.

Did you read the documentation and troubleshoot guide?

• I have read the documentation and troubleshoot guide

Environment

- **OS**: Ubuntu 20.04
- **Sage Version**: 10.0

Steps To Reproduce

K.<a> = NumberField(3*x^2 + 1)
P.<z,w> = ProjectiveSpace(K, 1)
phi = DynamicalSystem_projective([a*(z^2 + w^2),z*w])
phi.normalize_coordinates()

Expected Behavior

Should return a version of the point with normalized coordinates

Actual Behavior

the gcd step fails since it assumes clearing denominators gives back points in the ring of integers.

Additional Information

No response

[DaveWitteMorris]

Putting the "Steps to reproduce" into sage gives syntax errors, because it is not displaying properly. Please surround the code block with triple backticks.

Also, please delete "<title>" from the end of the title.

[videlec]

Hello. There are two errors rather than one I would say

• the problematic bit is that when K is a number field, normalize_coordinates tries to be "smart" using gcd
• when computing gcd over number fields, ultimately there is a following conversion failure (see below)

The conversion problem on number fields is

sage: K.maximal_order()(K(a))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-89ae56cf6326> in <module>
----> 1 K.maximal_order()(K(a))

/usr/lib/python3/dist-packages/sage/structure/parent.pyx in sage.structure.parent.Parent.__call__ (build/cythonized/sage/structure/parent.c:9458)()
    896         if mor is not None:
    897             if no_extra_args:
--> 898                 return mor._call_(x)
    899             else:
    900                 return mor._call_with_args(x, args, kwds)

/usr/lib/python3/dist-packages/sage/structure/coerce_maps.pyx in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cythonized/sage/structure/coerce_maps.c:4735)()
    159                 print(type(C), C)
    160                 print(type(C._element_constructor), C._element_constructor)
--> 161             raise
    162 
    163     cpdef Element _call_with_args(self, x, args=(), kwds={}):

/usr/lib/python3/dist-packages/sage/structure/coerce_maps.pyx in sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (build/cythonized/sage/structure/coerce_maps.c:4627)()
    154         cdef Parent C = self._codomain
    155         try:
--> 156             return C._element_constructor(x)
    157         except Exception:
    158             if print_warnings:

/usr/lib/python3/dist-packages/sage/rings/number_field/order.py in _element_constructor_(self, x)
   1239         V, _, embedding = self._K.vector_space()
   1240         if not embedding(x) in self._module_rep:
-> 1241             raise TypeError("Not an element of the order.")
   1242         return self._element_type(self, x)
   1243 

TypeError: Not an element of the order.

[bhutz]

Yes, the problem is that simply clearing denominators is not enough to ensure you are in the ring of integers (3a rather than a is the integral element). So I think the fix here is to be more careful in moving to the ring of integers.

[bhutz]

btw, there is a pull request made for this (35809), but it doesn't seem to be attached to this issue. How do those two get connected?

[DaveWitteMorris]

See the github documentation on linking a PR to an issue. Slightly changing the description of the PR should be enough. I'm not an expert, but instead of "fix issue #35797", I think it should say "fixes #35797". The manual approach would be to click on "Development" in the right-hand column of the PR web page, and add this issue. Either of these methods would need to be done by the author of the PR (or someone else with write access).

[guojing0]

See the github documentation on linking a PR to an issue. Slightly changing the description of the PR should be enough. I'm not an expert, but instead of "fix issue #35797", I think it should say "fixes #35797". The manual approach would be to click on "Development" in the right-hand column of the PR web page, and add this issue. Either of these methods would need to be done by the author of the PR (or someone else with write access).

Thank you. I did the first method ("fixes #35797"), and somehow Github automatically did the second for me.