We Keep Coding

How to solve OverflowError when generating same random numbers between R and Python using SyncRNG

I am trying to reproduce R codes in Python and I have to generate same random numbers in both languages. I know that using the same seed is not enough to get same random numbers and reading one of the answers on this platform regarding this topic I have discovered that there exists: SyncRNG library, which generates same random numbers between R and Python. Everything looks fine as long as I have discovered that on Python 3.7.3 I can generate via SyncRNG just one number because as soon as you iterate the procedure, for instance, with a for loop you get this error:
OverflowError: Python int too large to convert to C long.
As I was mentioning:
>>> from SyncRNG import SyncRNG
>>> s = SyncRNG(seed=123)
>>> r = s.rand()
>>> r
0.016173338983207965
and as we can see it works. The method ".rand()" generates random numbers between zero and one.
But if I try to iterate:
>>> from SyncRNG import SyncRNG
>>> s = SyncRNG(seed=123)
>>> b = []
>>> for i in range(5):
temp = s.rand()
b.append(temp)
and I get this:
OverflowError: Python int too large to convert to C long
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<pyshell#41>", line 2, in <module>
temp = s.rand()
File "C:\Users\Stefano\AppData\Local\Programs\Python\Python37\lib\site-packages\SyncRNG\__init__.py", line 27, in rand
return self.randi() * 2.3283064365387e-10
File "C:\Users\Stefano\AppData\Local\Programs\Python\Python37\lib\site-packages\SyncRNG\__init__.py", line 22, in randi
tmp = syncrng.rand(self.state)
SystemError: <built-in function rand> returned a result with an error set
So, I humbly ask if someone is able to solve this problem. If I lost old answers about this topic I'm sorry, please link them in the answer section.
Thank you!

This is not a solution, but a workaround. The overflow bug is not reproducible on my system. The workaround:
from SyncRNG import SyncRNG
s = SyncRNG(seed=123)
ct = 0
b = []
while ct < 5:
try:
temp = s.rand()
b.append(temp)
ct += 1
except OverflowError:
pass
Performance will be compromised due to the try/except on each loop.

Convert a sympy poly with imaginary powers to an mpmath mpc

I have a sympy poly that looks like:
Poly(0.764635937801645*I**4 + 7.14650839258644*I**3 - 0.667712176660315*I**2 - 2.81663805543677*I - 0.623299856233272, I, domain='RR')
I'm converting to mpc using the following code:
a = val.subs('I',1.0j)
b = sy.re(a)
c = sy.im(a)
d = mpmath.mpc(b,c)
Two questions.
Assuming my mpc and sympy type have equal precision (of eg 100 dps) is there a precision loss using this conversion from a to d?
Is there a better way to convert?
Aside: sympy seems to treat I just like a symbol here. How do I get sympy to simplify this polynomial?
Edit: Ive also noticed that the following works in place of a above:
a = val.args[0]

Strings and expressions
Root cause of the issue is seen in val.subs('I', 1.0j) -- you appear to pass strings as arguments to SymPy functions. There are some valid uses for this (such as creation of high-precision floats), but when symbols are concerned, using strings is a recipe for confusion. The string 'I' gets implicitly converted to SymPy expression Symbol('I'), which is different from SymPy expression I. So the answer to
How do I get sympy to simplify this polynomial?
is to revisit the process of creation of that polynomial, and fix that. If you really need to create it from a string, then use locals parameter:
>>> S('3.3*I**2 + 2*I', locals={'I': I})
-3.3 + 2*I
Polynomials and expressions
If the Poly structure is not needed, use the method as_expr() of Poly to get an expression from it.
Conversion to mpmath and precision loss
is there a precision loss using this conversion from a to d?
Yes, splitting into real and imaginary and then recombining can lead to precision loss. Pass a SymPy object directly to mpc if you know it's a complex number. Or to mpmathify if you want mpmath to decide what type it should have. An example:
>>> val = S('1.111111111111111111111111111111111111111111111111')*I**3 - 2
>>> val
-2 - 1.111111111111111111111111111111111111111111111111*I
>>> import mpmath
>>> mpmath.mp.dps = 40
>>> mpmath.mpc(val)
mpc(real='-2.0', imag='-1.111111111111111111111111111111111111111111')
>>> mpmath.mpmathify(val)
mpc(real='-2.0', imag='-1.111111111111111111111111111111111111111111')
>>> mpmath.mpc(re(val), im(val))
mpc(real='-2.0', imag='-1.111111111111111111111111111111111111111114')
Observations:
When I is actual imaginary unit, I**3 evaluates fo -I, you don't have to do anything for it to happen.
A string representation of high-precision decimal is used to create such a float in SymPy. Here S stands for sympify. One can also be more direct and use Float('1.1111111111111111111111111')
Direct conversion of a SymPy complex number to an mpmath complex number is preferable to splitting in real/complex and recombining.
Conclusion
Most of the above is just talking around an XY problem. Your expression with I was not what you think it was, so you tried to do strange things that were not needed, and my answer is mostly a waste of time.

I'm adding my own answer here, as FTP's answer, although relevant and very helpful, did not (directly) resolve my issue (which wasn't that clear from the question tbh). When I ran the code in his example I got the following:
>>> from sympy import *
>>> import mpmath
>>> val = S('1.111111111111111111111111111111111111111111111111')*I**3 - 2
>>> val
-2 - 1.111111111111111111111111111111111111111111111111*I
>>> mpmath.mp.dps = 40
>>> mpmath.mpc(val)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\mpmath\ctx_mp_python.py", line 373, in __new__
real = cls.context.mpf(real)
File "C:\Python27\lib\site-packages\mpmath\ctx_mp_python.py", line 77, in __new__
v._mpf_ = mpf_pos(cls.mpf_convert_arg(val, prec, rounding), prec, rounding)
File "C:\Python27\lib\site-packages\mpmath\ctx_mp_python.py", line 96, in mpf_convert_arg
raise TypeError("cannot create mpf from " + repr(x))
TypeError: cannot create mpf from -2 - 1.111111111111111111111111111111111111111111111111*I
>>> mpmath.mpmathify(val)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\mpmath\ctx_mp_python.py", line 662, in convert
return ctx._convert_fallback(x, strings)
File "C:\Python27\lib\site-packages\mpmath\ctx_mp.py", line 614, in _convert_fallback
raise TypeError("cannot create mpf from " + repr(x))
TypeError: cannot create mpf from -2 - 1.111111111111111111111111111111111111111111111111*I
>>> mpmath.mpc(re(val), im(val))
mpc(real='-2.0', imag='-1.111111111111111111111111111111111111111114')
>>> mpmath.mpmathify(val)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python27\lib\site-packages\mpmath\ctx_mp_python.py", line 662, in convert
return ctx._convert_fallback(x, strings)
File "C:\Python27\lib\site-packages\mpmath\ctx_mp.py", line 614, in _convert_fallback
raise TypeError("cannot create mpf from " + repr(x))
TypeError: cannot create mpf from -2 - 1.111111111111111111111111111111111111111111111111*I
Updating my sympy (1.0->1.1.1) and mpmath (0.19->1.0.0) fixed the exceptions. I did not test which of these upgrades actually resolved the issue.

np.roots() causing 'float() argument must be a string or a number' with mp.mpc type problems

I was getting this error:
> float() argument must be a string or a number
So, why does this happen?(I tried commands like np.asarray() but it keeps failing).
mp.mpc(cmath.rect(a,b)))

The items in raizes are actually mpmath.mpc instances rather than native Python complex floats. numpy doesn't know how to deal with mpmath types, hence the TypeError.
You didn't mention mpmath at all in your original question. The problem would still have been easy to diagnose if you had posted the full traceback, rather than cutting off the most important part at the end:
In [10]: np.roots(Q)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-10-f3a270c7e8c0> in <module>()
----> 1 np.roots(Q)
/home/alistair/.venvs/mpmath/lib/python3.6/site-packages/numpy/lib/polynomial.py in roots(p)
220 # casting: if incoming array isn't floating point, make it floating point.
221 if not issubclass(p.dtype.type, (NX.floating, NX.complexfloating)):
--> 222 p = p.astype(float)
223
224 N = len(p)
TypeError: float() argument must be a string or a number, not 'mpc'
Whenever you ask for help with debugging on this site, please always post the whole traceback rather than just (part of) the last line - it contains a lot of information that can be helpful for diagnosing the problem.
The solution is simple enough - just don't convert the native Python complex floats returned by cmath.rect to mpmath.mpc complex floats:
raizes = []
for i in range(2*n):
a, f = cmath.polar(l[i])
if((f>np.pi/2) or (f<-np.pi/2)):
raizes.append(cmath.rect(a*r,f))
Q = np.poly(raizes)
print(np.roots(Q))
# [-0.35372430 +1.08865146e+00j -0.92606224 +6.72823602e-01j
# -0.35372430 -1.08865146e+00j -1.14467588 -9.11902316e-16j
# -0.92606224 -6.72823602e-01j]

How to detect overflow while arithmetic in python?

I am working on a analysis problem in python in which I have to work on big floating point numbers and was performing some operations on it. My codes seems to break in between; looking carefully I found that sometimes a simple add operation would return inf it must be an overflow.
>>> a = float(2**1022) + float(2**1023)
>>> print a
1.348269851146737e+308
>>> a = float(2**1023) + float(2**1023)
>>> print a
inf
>>>
How do we check for overflow in python while floating point operation since instead of giving a OverflowError it silently gives a value inf.

I can only imagine checking if abs(a)==float('inf'): raise OverflowError()…

Use an arbitrary precision library like GMPY and you won't need to worry.

Disclaimer: I maintain gmpy2.
The gmpy2 library supports both arbitrary precision (to decrease the occurrences of overflow) and the ability to trap on floating point events. Here is an example of modify the context to automatically raise an exception when an overflow occurs.
>>> import gmpy2
>>> from gmpy2 import get_context,set_context, ieee, mpfr
>>> set_context(ieee(64))
>>> get_context()
context(precision=53, real_prec=Default, imag_prec=Default,
round=RoundToNearest, real_round=Default, imag_round=Default,
emax=1024, emin=-1073,
subnormalize=True,
trap_underflow=False, underflow=False,
trap_overflow=False, overflow=False,
trap_inexact=False, inexact=False,
trap_invalid=False, invalid=False,
trap_erange=False, erange=False,
trap_divzero=False, divzero=False,
trap_expbound=False,
allow_complex=False)
>>> get_context().trap_overflow=True
>>> get_context()
context(precision=53, real_prec=Default, imag_prec=Default,
round=RoundToNearest, real_round=Default, imag_round=Default,
emax=1024, emin=-1073,
subnormalize=True,
trap_underflow=False, underflow=False,
trap_overflow=True, overflow=False,
trap_inexact=False, inexact=False,
trap_invalid=False, invalid=False,
trap_erange=False, erange=False,
trap_divzero=False, divzero=False,
trap_expbound=False,
allow_complex=False)
>>> mpfr(2**1023) + mpfr(2**1023)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
gmpy2.OverflowResultError: 'mpfr' overflow in "addition"
>>>

Different precision in math.sin and math.cos

I have a simple question for the computation of a sin and cos of a radiant in python.
It seems to me, that the sin is limited to values bigger than "x.xe-8" while cos is capable to compute much smaller values, like "x.xe-90" in my example.
Is there a way (except round before the sin) to get the sin to work properly (within its precision limits of course).
>>> import math
>>> math.sin(1.0e-8)
1e-08
>>> math.sin(1.0e-9)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> math.cos(1.0e-90)
1.0
Edit: The problem was the OS. There is an update available. (https://www.suse.com/support/update/announcement/2012/suse-ru-20120681-1.html)

The problem was the OS. There is an update for Suse Enterprise 11.2 available.
--> https://www.suse.com/support/update/announcement/2012/suse-ru-20120681-1.html

But sin(x) ~ x around the origin so why are you so worried by this? Subtracting x**3/6.0 must get you close enough for most calcs (if not, adding x**5/120.0 must).

I had a look at the code (Python 2.7.5). You can find the relevant lines in Modules/mathmodule.c:
r = (*func)(x);
PyFPE_END_PROTECT(r);
if (Py_IS_NAN(r)) {
if (!Py_IS_NAN(x))
errno = EDOM;
else
errno = 0;
}
else if (Py_IS_INFINITY(r)) {
if (Py_IS_FINITE(x))
errno = can_overflow ? ERANGE : EDOM;
else
errno = 0;
}
func is a pointer to the system sin function, and can_overflow is 0. So your system’s sin either returns NaN or infinity for the given input.