8000 randint output have different dtype on Linux and Windows · Issue #10317 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

randint output have different dtype on Linux and Windows #10317

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rth opened this issue Jan 3, 2018 · 7 comments
Closed

randint output have different dtype on Linux and Windows #10317

rth opened this issue Jan 3, 2018 · 7 comments

Comments

@rth
Copy link
Contributor
rth commented Jan 3, 2018 •
edited
Loading

The output dtype of np.random.randint is not cross-platform compatible,

import numpy as np
np.random.randint(10, size=2).dtype

produces an array of int64 on Linux and an array of int32 on Windows.

Tested versions,

import platform; print(platform.platform())
import sys; print("Python", sys.version)
import numpy; print("NumPy", numpy.__version__)

Linux

Linux-3.19.0-58-generic-x86_64-with-debian-jessie-sid
Python 3.6.3 |Anaconda, Inc.| (default, Nov 20 2017, 20:41:42)  [GCC 7.2.0]
NumPy 1.13.3

Windows

Windows-10-10.0.14393-SP0
Python 3.6.3 |Anaconda, Inc.| (default, Nov  8 2017, 15:10:56) [MSC v.1900 64 bit (AMD64)]
NumPy 1.13.3

This is due to the fact that the default input parameter is dtype='l'. I saw that there was a lot of related discussion leading to #6910 but I was wondering if there were reasons that prevented setting dtype=np.int64 by default there.

The current behaviour is problematic with any typed code (e.g. Cython / GPU related), and, for instance led to maciejkula/spotlight#82

cc @gfyoung @charris
@rth rth mentioned this issue Jan 3, 2018
Merged
@eric-wieser
Copy link
Member
eric-wieser commented Jan 3, 2018 •
edited
Loading

A much simpler reproduction is np.dtype(int).itemsize, which is 4 on windows, and 8 elsewhere. Having the dtype default to int is reasonable, but we might want to change the meaning of np.dtype(int)

np.array(1) also falls afoul of these different dtypes.

@pv
Copy link
Member
pv commented Jan 3, 2018 via email

@bashtage
Copy link
Contributor
bashtage commented Jan 3, 2018 •
edited
Loading

There is no fundamental reason but the requirement for same inputs = same outputs (conditional on platform, compiler, etc.) means that this cannot be changed in the current RandomState implementation. It is just legacy. This pattern of int32 on Windows and int64 otherwise is related for virtually all integer generators. Ideally all integer-based generators would default to int64.

@charris
Copy link
Member
charris commented Jan 3, 2018

The default was chosen for backwards compatibility, although it is already somewhat broken as it is OS dependent. The simplest solution is to explicitly specify the dtype.

@charris
Copy link
Member
charris commented Jan 3, 2018 •
edited
Loading

Note that these problems with the long C type are inherited from early Python before it became fully 64 bit compatible with Python 2.5. We were still supporting Python 2.4 as recently as 1.7 (2013).

@rth
Copy link
Contributor Author
rth commented Jan 4, 2018

I understand, thank you for the explanations.

@mattip
Copy link
Member
mattip commented Jun 13, 2018

Closing, please reopen if you wish to pursue changing this

@mattip mattip closed this as completed Jun 13, 2018
@weiji14 weiji14 mentioned this issue May 21, 2020
Merged
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@pv @charris @eric-wieser @rth @mattip @bashtage
0