doctest fix for infinities break the hash contract

[rwst]

sage: hash(-oo)
-9223372036854775808
sage: hash(SR(-oo))
1390175631
sage: hash(oo)
9223372036854775807
sage: hash(SR(oo))
1577573780
sage: hash(unsigned_infinity)
9223372036854775806
sage: hash(SR(unsigned_infinity))
2904791665

Fixed in pynac/pynac#126

Component: symbolics

Author: Ralf Stephan

Branch/Commit: 9eb6d88

Reviewer: Travis Scrimshaw

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

[rwst]

Dependencies: #19927

[rwst]

comment:1

#19927 has to be fixed in Sage before Pynac can copy hash values from there.

[rwst]

Description changed:

--- 
+++ 
@@ -9,8 +9,8 @@
 sage: hash(SR(oo))
 1577573780
 sage: hash(unsigned_infinity)
-TypeError: <class 'sage.rings.infinity.UnsignedInfinity'> is not hashable
+9223372036854775806
 sage: hash(SR(unsigned_infinity))
 2904791665
 ```
-
+The reason is that (at least with `-oo`) in Pynac they can be represented as an `expair` and such hashes are calculated using `all<sup>(rest</sup>coeff)^overall_coeff`.

[rwst]

Description changed:

--- 
+++ 
@@ -14,3 +14,14 @@
 2904791665
 ```
 The reason is that (at least with `-oo`) in Pynac they can be represented as an `expair` and such hashes are calculated using `all<sup>(rest</sup>coeff)^overall_coeff`.
+
+So the question is also why Pynac needs an `expair` for `oo` but not for `pi`:
+
+```
+sage: SR(1*pi)._dbgprinttree()
+pi (constant) @0x2844e00, hash=0xa6ee0bd1, flags=0xf
+sage: SR(oo)._dbgprinttree()
+infinity (infinity) @0x1e78ef0, hash=0x0, flags=0x7
+    1 (numeric) @0x1cbe380, hash=0x5a00e46d, flags=0x7
+```
+

[rwst]

Description changed:

--- 
+++ 
@@ -24,4 +24,4 @@
 infinity (infinity) @0x1e78ef0, hash=0x0, flags=0x7
     1 (numeric) @0x1cbe380, hash=0x5a00e46d, flags=0x7
 ```
-
+See https://github.com/pynac/pynac/issues/126

[rwst]

Description changed:

--- 
+++ 
@@ -13,15 +13,5 @@
 sage: hash(SR(unsigned_infinity))
 2904791665
 ```
-The reason is that (at least with `-oo`) in Pynac they can be represented as an `expair` and such hashes are calculated using `all<sup>(rest</sup>coeff)^overall_coeff`.
 
-So the question is also why Pynac needs an `expair` for `oo` but not for `pi`:
-
-```
-sage: SR(1*pi)._dbgprinttree()
-pi (constant) @0x2844e00, hash=0xa6ee0bd1, flags=0xf
-sage: SR(oo)._dbgprinttree()
-infinity (infinity) @0x1e78ef0, hash=0x0, flags=0x7
-    1 (numeric) @0x1cbe380, hash=0x5a00e46d, flags=0x7
-```
-See https://github.com/pynac/pynac/issues/126
+Fixed in https://github.com/pynac/pynac/issues/126

[rwst]

Changed dependencies from #19927 to none

[rwst]

Upstream: Fixed upstream, in a later stable release.

[rwst]

comment:6

It's fixed now and just needs to be doctested.

[rwst]

Changed upstream from Fixed upstream, in a later stable release. to none