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

[behackl]

New commits:

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

[rws]

Patchbot shows doctest fails.

[behackl]

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.

[git]

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

​591899b

return false in case of NotImplementedError

[behackl]

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: ​https://github.com/pynac/pynac/pull/160.

[vdelecroix]

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]

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.

[mmezzarobba]

I doubt it is such a good idea to special-case finite fields here. Why does py_imag default to returning True in the first place?! And as for returning results based on the parent of the wrapped object, I'd be tempted to base the logic on whether the parent has coercions to things like {Real,Complex}Field(mpfr_prec_min()) instead of having explicit lists of “real” and “non-real” parents.

[behackl]

Replying to mmezzarobba:

I doubt it is such a good idea to special-case finite fields here. Why does py_imag default to returning True in the first place?!

This is because if in doubt py_is_real asks py_imag whether the imaginary part is 0---which is the case for these elements, because if in doubt, py_imag assumes that the imaginary part is 0. ;-)

And as for returning results based on the parent of the wrapped object, I'd be tempted to base the logic on whether the parent has coercions to things like {Real,Complex}Field(mpfr_prec_min()) instead of having explicit lists of “real” and “non-real” parents.

This might be an approach worth pursuing.

[rws]

Now (with #20312) both flags are false. Can this case be considered to be fixed? Then just a doctest would be needed here.

[rws]

With #22162 this would return Unknown, and a doctest already exist (changed in #22162) so I think this is a duplicate now.

[cheuberg]

In any case, this produces a merge conflict.

[rws]

Replying to cheuberg:

In any case, this produces a merge conflict.

Needs work on a duplicate request!?

[cheuberg]

sorry, did not see the sage-duplicate/invalid/wontfix milestone.

[cheuberg]

I see that the problem is fixed; can you tell me where the doctest is? I did not see it at first glance.

[rws]

It was added with ​https://github.com/sagemath/sage/commit/11e2b784 (bottom)

[cheuberg]

Problem is fixed and doctest has been included in #20475.