Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior when an array of floats is subtracted from a very large integer. #16689

Closed
mmngreco opened this issue Jun 25, 2020 · 2 comments

Comments

@mmngreco
Copy link

Doing some calculations I discover this unexpected behavior related with
dtypes. I hope some of you can point me if this is a bug or I'm doing
something wrong.

Reproducing code example:

Here is a minimal peace of my code which tries to reproduce the problem:

import numpy as np

# VERSIONS USED
np.__version__ #  '1.18.1'
np.__version__ #  '1.19.0'

x = 731965.048356481480000000000000000000
x_arr = np.array([x])
big_int = 86400000000000
cnst = 719529

# THIS WORKS
arr1 = (x_arr - cnst) * big_int
out1 = arr1.astype("datetime64[ns]")

# THIS FAILS
arr2 = x_arr * big_int - cnst * big_int
out2 = arr2.astype("datetime64[ns]")

# WORKAROUND
big_int = 86400000000000.  # NOW IS A FLOAT
arr3 = x_arr * big_int - cnst * big_int
out3 = arr3.astype("datetime64[ns]")

MWE

Here some code that I use for debugging a minimal reproducible example that
shows this unexpected behavior.

def check_dtype(big_int):
    a = np.array([731965.04835648148]) * big_int
    b = 719529 * big_int
    c = a - b
    return c.dtype

works_int = 20000000000000
fails_int = 30000000000000
check_dtype(works_int)  # dtype('float64')
check_dtype(fails_int)  # dtype('O')

Numpy/Python version information:

import sys, numpy; print(numpy.__version__, sys.version)
1.19.0 3.7.7 (default, Mar 26 2020, 15:48:22)
[GCC 7.3.0]
@mmngreco mmngreco changed the title Unexpected behavior when an array is subtracted from a very large integer. Unexpected behavior when an array of floats is subtracted from a very large integer. Jun 25, 2020
@seberg
Copy link
Member

seberg commented Jun 25, 2020

This is a known issue, there should be a few duplicates around in recent past also. The problem is that when NumPy encounters a Python integers it will try the dtypes:

  • long (np.int_) – on many systems identical to np.int64
  • np.int64
  • np.uint64
  • object

You can do even more fun things if you mix in integers that go to unsigned... I will probably propose to deprecate once my other PR is in, I think. Not sure we will actually do it, but getting random types has lots of traps, in almost all cases uses do alraedy get the default integer (whatever that is, int32, or int64). Anyway, closing as duplicate of: gh-16287

@seberg seberg closed this as completed Jun 25, 2020
@seberg
Copy link
Member

seberg commented Jun 25, 2020

But thanks for reporting, its good to know that it is creating issues in the wild... and it is one of the trickier/more hidden things!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants