properties of converted finite field elements are wrong

[behackl]

This should not happen:

sage: k.<a> = GF(9)
sage: SR(a).is_real()
True
sage: SR(a).is_positive()
True

Depends on #20312

CC: @rwst

Component: symbolics

Author: Benjamin Hackl

Reviewer: Clemens Heuberger

Issue created by migration from https://trac.sagemath.org/ticket/20162

[behackl]

New commits:

443fbf8	finite field elements are not reals
a822d5d	add doctests for is_real/is_positive

[behackl]

Branch: u/behackl/symbolic/finite-field-reals

[behackl]

Commit: a822d5d

[rwst]

comment:2

Patchbot shows doctest fails.

[behackl]

comment:3

Ah, yes. Maybe I need another way of finding out whether a parent is a finite field; is_finite seems to throw NotImplementedErrors here. That would fix the failures in schemes/elliptic_curves/heigth.py.

However, I'm not sure about the segmentation fault in expression.pyx, calling

sage: (Mod(2,7)*x^2 + Mod(2,7))^7

from sage -gdb prints the line

Program received signal SIGSEGV, Segmentation fault.
GiNaC::add::integer_content (this=0x3019c20) at normal.cpp:325

It seems that something requires the expression to be a real in order for the power to work. This is bad.

Maybe I'll investigate later; have to go now.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

591899b

return false in case of NotImplementedError

[sagetrac-git]

Changed commit from a822d5d to 591899b

[behackl]

comment:5

The last commit fixes the doctest failures in schemes/elliptic_curves/height.py, but not the segmentation fault. Unfortunately, the reason for that lies in pynac---a fix can be found here: pynac/pynac#160.

[videlec]

comment:6

Just to share some related fun with quotients of the integer ring

sage: cos(Zmod(7)(3))
-0.989992496600445
sage: cos(Zmod(10)(3))
1
sage: cos(Zmod(15)(3))
1

[behackl]

comment:7

With pynac-0.6.4 (#20134):

sage: cos(Zmod(7)(3))
-0.989992496600445
sage: cos(Zmod(10)(3))
-0.989992496600445
sage: cos(Zmod(15)(3))
-0.989992496600445

In an ideal world, this would probably raise a ValueError or so. This way it is at least consistent.