Repository navigation
Reticulate can't handle large integer values: Seems to experience integer overflow when it exceeds the limit for 32-bit signed integers #1647
Description
The easiest way of seeing this is to run:
> py_eval("10000**2")
[1] 100000000
> py_eval("100000**2")
[1] -1
To give another example: I'm using the Splink package to do probabilistic record linkage. At one point I run the linker.training.estimate_probability_two_random_records_match() function, which calculates a Cartesian product and stores it in an interim variable. My code runs fine in native Python but returns the following error when I use reticulate():
ValueError: Deterministic matching rules led to more observed matches than is consistent with supplied recall. With these rules, recall must be at least -0.00.
A line of Splink code before this error message is:
num_total_comparisons = summary_record["cartesian"]
When I display the value of num_total_comparisons, it shows as:
-2147483648
Which is -2^31, the minimum value for a 32-bit signed integer. When I reduce the size of my data frame so that the Cartesian product of the number of records is less than 2^31, it runs fine.
Let me know if you need any more info. Thanks.
Activity
wfulp commentedon Oct 22, 2026
Still reproduces on the current CRAN release, reticulate 1.47.0 (and 1.46.0), R 4.6.0 (aarch64-apple-darwin23), Python 3.12.6 / 3.13.1 / 3.14.2, with
Rscript --vanilla. The result is the low 32 bits of the value, with no warning, and the boundary values becomeNA:The silent wrong value is what hurts: a 2 TB byte limit returned by a Python API (2000000000000) arrived in R as -1454759936, and nothing signalled it.
Even without the full bit64 support discussed in #323 / #590, converting ints that don't fit in an R integer to double (exact up to 2^53), or at least warning when that happens, would make this safe. Related: #1835 (same report).