Closed strogdon closed 3 years ago
I see there is a new version of mpmath in the tree, what is your version? I have 1.1.0 here.
I'm using 1.2.1
.
Can you downgrade to check if that's it?
It's no longer in the tree but I think I can do a local overlay.
I see, it was stabilized on Monday and 1.1.0 was removed in the same sweep https://packages.gentoo.org/packages/dev-python/mpmath/changelog. My tree still has it as unstable, the Australian mirror has been a bit laggy lately. I will investigate locally because if, as I suspect, it is the cause, the damage will be widespread.
OK, because of my time zone it was probably Tuesday for me, which makes it not quite as laggy.
Yes definitely the cause.
I suspect this
Compatibility:
* Enable sage backend by default only if SAGE_ROOT is set (Pauli Virtanen)
in https://github.com/fredrik-johansson/mpmath/blob/master/CHANGES
fbissey@moonloop ~ $ sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
too many failed tests, not using stored timings
Running doctests with ID 2021-03-18-13-14-48-fb25a05d.
Using --optional=dochtml,memlimit,pip,sage
Doctesting 1 file.
sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
**********************************************************************
File "/usr/lib/python3.9/site-packages/sage/calculus/calculus.py", line 372, in sage.calculus.calculus
Failed example:
[f[0].n() for f in _.coefficients()] # numerical coefficients to make comparison easier; Maple 12 gives same answer
Exception raised:
Traceback (most recent call last):
File "sage/symbolic/expression.pyx", line 6186, in sage.symbolic.expression.Expression.numerical_approx (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:37043)
x = x._convert(kwds)
File "sage/symbolic/expression.pyx", line 1495, in sage.symbolic.expression.Expression._convert (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:10451)
cdef GEx res = self._gobj.evalf(0, kwds)
File "sage/libs/pynac/pynac.pyx", line 2139, in sage.libs.pynac.pynac.py_psi2 (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/pynac/pynac.cpp:25306)
return mpmath_utils.call(mpmath.psi, n, x, prec=prec)
File "sage/libs/mpmath/utils.pyx", line 439, in sage.libs.mpmath.utils.call (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:7129)
y = mpmath_to_sage(y, prec)
File "sage/libs/mpmath/utils.pyx", line 272, in sage.libs.mpmath.utils.mpmath_to_sage (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:5518)
mpfr_from_mpfval(y.value, x._mpf_)
File "sage/libs/mpmath/utils.pyx", line 167, in sage.libs.mpmath.utils.mpfr_from_mpfval (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:4702)
sign, man, exp, bc = x
TypeError: Cannot convert mpz to sage.rings.integer.Integer
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/sage/doctest/forker.py", line 714, in _run
self.compile_and_execute(example, compiler, test.globs)
File "/usr/lib/python3.9/site-packages/sage/doctest/forker.py", line 1133, in compile_and_execute
exec(compiled, globs)
File "<doctest sage.calculus.calculus[101]>", line 1, in <module>
[f[Integer(0)].n() for f in _.coefficients()] # numerical coefficients to make comparison easier; Maple 12 gives same answer
File "<doctest sage.calculus.calculus[101]>", line 1, in <listcomp>
[f[Integer(0)].n() for f in _.coefficients()] # numerical coefficients to make comparison easier; Maple 12 gives same answer
File "sage/structure/element.pyx", line 885, in sage.structure.element.Element.n (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/structure/element.c:8385)
return self.numerical_approx(prec, digits, algorithm)
File "sage/symbolic/expression.pyx", line 6190, in sage.symbolic.expression.Expression.numerical_approx (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:37116)
x = x._convert(kwds)
File "sage/symbolic/expression.pyx", line 1495, in sage.symbolic.expression.Expression._convert (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/symbolic/expression.cpp:10451)
cdef GEx res = self._gobj.evalf(0, kwds)
File "sage/libs/pynac/pynac.pyx", line 2139, in sage.libs.pynac.pynac.py_psi2 (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/pynac/pynac.cpp:25306)
return mpmath_utils.call(mpmath.psi, n, x, prec=prec)
File "sage/libs/mpmath/utils.pyx", line 439, in sage.libs.mpmath.utils.call (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:7129)
y = mpmath_to_sage(y, prec)
File "sage/libs/mpmath/utils.pyx", line 272, in sage.libs.mpmath.utils.mpmath_to_sage (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:5518)
mpfr_from_mpfval(y.value, x._mpf_)
File "sage/libs/mpmath/utils.pyx", line 167, in sage.libs.mpmath.utils.mpfr_from_mpfval (/dev/shm/portage/sci-mathematics/sage-9999/work/sage-9999/src-python3_9/build/cythonized/sage/libs/mpmath/utils.c:4702)
sign, man, exp, bc = x
TypeError: Cannot convert mpz to sage.rings.integer.Integer
**********************************************************************
1 item had failures:
1 of 113 in sage.calculus.calculus
[429 tests, 1 failure, 9.93 s]
----------------------------------------------------------------------
sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 10.0 seconds
cpu time: 10.6 seconds
cumulative wall time: 9.9 seconds
fbissey@moonloop ~ $ SAGE_ROOT=1 sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
too many failed tests, not using stored timings
Running doctests with ID 2021-03-18-13-18-15-7c4bcb36.
Using --optional=dochtml,memlimit,pip,sage
Doctesting 1 file.
sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
[429 tests, 9.94 s]
----------------------------------------------------------------------
All tests passed!
----------------------------------------------------------------------
Total time for all tests: 10.0 seconds
cpu time: 10.7 seconds
cumulative wall time: 9.9 seconds
Hum, sage may have to changed in too many places to make viable as a patch in sage-on-gentoo. But we may still try something basic.
As you indicated on https://github.com/fredrik-johansson/mpmath/pull/466 setting MPMATH_SAGE=1
seems to work. Any harm in setting MPMATH_SAGE
globally?
Because the potential change to make is in a pyx file, a rebuild of sage is required for testing my idea. Due to my current schedule I won't know if it is helpful for several hours. I am trying this simple patch to sage
diff --git a/sage/libs/mpmath/utils.pyx b/sage/libs/mpmath/utils.pyx
index d6c9eee..e7fdec2 100644
--- a/sage/libs/mpmath/utils.pyx
+++ b/sage/libs/mpmath/utils.pyx
@@ -419,6 +419,8 @@ def call(func, *args, **kwargs):
3.141592653589793j
"""
+ import os
+ os.environ['MPMATH_SAGE'] = 1
from mpmath import mp
orig = mp.prec
prec = kwargs.pop('prec', orig)
In answer to your question, that makes it the default behavior when sage is installed which may or may not be desirable. In fact, I am fairly sure it not being the default behavior when there is a system sage installed was upstream's intention.
I think, if patching is to work, os.environ['MPMATH_SAGE'] = 1
should be os.environ['MPMATH_SAGE'] = "1"
.
>>> import os
>>> os.environ['MPMATH_SAGE'] = 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python-exec/python3.9/../../../lib/python3.9/os.py", line 684, in __setitem__
value = self.encodevalue(value)
File "/usr/lib/python-exec/python3.9/../../../lib/python3.9/os.py", line 756, in encode
raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not int
I get confused about this.
That's an oversight on my part. You are obviously right. One sage install for nothing, it exhibit exactly the error you show above.
OK, with 1 -> "1"
I still get the failures. Perhaps MPMATH_SAGE
could be set in the ebuild?
What would that achieve? Do you have problems during build? Or do you mean install an environment variable in /etc/env.d
?
Whatever is needed so that MPMATH_SAGE
is present from a sage shell. After building with MPMATH_SAGE
set correctly I have
(sage-sh) steven@hp-probook:~$ env | grep SAGE
SAGE_DEBUG=yes
SAGE_RC_FILE=/home/steven/.sage/sagerc
SAGE_STARTUP_FILE=/home/steven/.sage/init.sage
DOT_SAGE=/home/steven/.sage
but
$ MPMATH_SAGE=1 sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
too many failed tests, not using stored timings
Running doctests with ID 2021-03-17-21-16-09-f330213e.
Using --optional=dochtml,memlimit,sage
Doctesting 1 file.
sage -t --long --random-seed=0 /usr/lib/python3.9/site-packages/sage/calculus/calculus.py
[429 tests, 11.85 s]
----------------------------------------------------------------------
All tests passed!
Yes, make it a "true" sage variable that gets in the environment as well when sage is run. The variables you grepped above are explicitly setup in the sage executable and are only really used when you start sage with the "sage" executable. It wouldn't work if you import sage from a python shell which is also something you can do with sage-on-gentoo and in fact that you should be able to do now in vanilla sage, so long as you are using the right interpreter and possibly have the right PATHs set.
There may still be things to dig around using sage_conf.
Not really working. It looks like for now putting either SAGE_ROOT=bar
or MPMATH_SAGE=foo
in the environment is the quick fix. I may have to put it in sage ebuilds for now.
Now installing an env.d variable as a temporary fix. Hopefully something better will come along.
$ cat /etc/env.d/99sage
MPMATH_SAGE=1
This does not work here. I still see the
TypeError: Cannot convert mpz to sage.rings.integer.Integer
when doctesting. Also, I noticed that at least one doctest in comment:1 is not related to MPMATH
.
sage -t --long --random -seed=0 /usr/lib/python3.9/site-packages/sage/misc/sageinspect.py
It seems odd to me because the failure mentions
ModuleNotFoundError: No module named '_home_steven__sage_temp_hp_probook_8631_tmp_md9yd6zb_pyx_0'
But I don't want to get side-tracked from the present issue.
Is MPMATH_SAGE in your environment? env
should tell you, if not you may need a new terminal or to do a "env_update"
No MPMATH_SAGE in my environment. And after env-update
# env | grep SAGE
is empty.
Hum, I had to run env-update as root, logout my ssh session and when I logged back in it was there.
OK, logged out as root and then back in as root and the variable is there. The variable is not present when a new terminal is started as a normal user. However, if I ssh to myself (same machine) in this terminal then the variable is present. Something is not being sourced but not sure what it is.
This may be an issue with how your desktop environment start new terminals, new terminal tabs in konsole (kde) gets it. The way to get it as a user without restarting terminals is not env-update
but . /etc/profile
.
I suspect that. If I remotely ssh to the machine the variable is present. If I login through one of the tty's then the variable is present. The variable is in profile.env
.
Had to logout of window manager and then in again to permanently fix the issue. Maybe a better way but I'm up to speed now - sourcing /etc/profile was only a terminal specific fix. Strange.
If you don't have the sageinspect.py
then I'll open another issue. I don't believe I have seen it previously.
sageinspect.py
does take a long time here, but it does pass.
Upstream sage ticket https://trac.sagemath.org/ticket/25445 as I noted on sage-devel the kind of behavior we see is probably due to misuse of mpmath's API.
I am closing this. Not that there isn't much more to do but it is really out of scope of the overlay.
This is a fresh install of s-o-g and I have some
odd
failures.I may have missed some items but when doctesting
TypeError: Cannot convert mpz to sage.rings.integer.Integer
seems to be pervasive, i.e.