BUG: One Element Array Inputs Return Scalars in np.random

[gfyoung]

Fixes issue raised in #4263 in which np.random methods returned scalars when passed one-element array inputs. This is because one-element ndarrays can be cast to integers / floats, which is what functions like PyFloat_AsDouble do before converting to the intended data type.

This commit changes the check used to determine whether the inputs are purely scalar by, as suggested by @rkern, converting all inputs to arrays and checking if the resulting shape is an empty tuple (scalar) or not (array).

[gfyoung]

PR is currently WIP because I still need to add a test to make sure that this behavior does not resurface. However, I just want to make sure that my changes aren't breaking any existing tests.

[jaimefrio]

Is this double comparison valid Cython? Or does it end comparing True (or False) to ()?

[gfyoung]

It seems to have worked. I tested the methods briefly by hand (more formal testing is coming though!), and I didn't have any issues with the double (or even triple) comparison with regards to output data type.

[gfyoung]

I should add that while I do not know the validity of chained comparisons in Cython, I know it is valid in pure Python. I guess since you can compile pure Python with Cython, it should then be valid by extension? A quick look over the Cython docs does not indicate any issues with handling such chains.

[jaimefrio]

Yup, it is the Python thing, guess what confused me was the double ==, but it does what it is expected to:

In [184]: 0 == 0 == 0
Out[184]: True

In [185]: (0 == 0) == 0
Out[185]: False

In [186]: 0 == (0 == 0)
Out[186]: False

[gfyoung]

Tests have been added, and Travis + Appveyor are happy. Should be good to merge as is, as I can uncomment the randint test after a rebase in #6938.

[jaimefrio]

This change makes a call to np.random.uniform(0, 1) 5x slower in my system:

In [39]: %timeit np.random.uniform(0, 1)
# current master
The slowest run took 19.17 times longer than the fastest. This could mean that an intermediate result is being cached 
1000000 loops, best of 3: 199 ns per loop
# this PR
The slowest run took 26.30 times longer than the fastest. This could mean that an intermediate result is being cached 
1000000 loops, best of 3: 988 ns per loop

Not sure if this is really relevant, as bulk calling e.g. np.random.uniform(0, 1, 1000), only shows a much smaller slowdown (15us to 16us), but would again like to hear other opinions.

[gfyoung]

@jaimefrio : Should we wait longer, or can this be merged?

[jaimefrio]

You can get some of the speed back if you change the condition:

if np.array(low).shape == np.array(high).shape == ():

to:

if (not (isinstance(low, np.ndarray) and low.shape) and
                not (isinstance(high, np.ndarray) and high.shape))

In [2]: %timeit np.random.uniform(0, 1)
# this PR
1000000 loops, best of 3: 1.04 µs per loop
# my changes
1000000 loops, best of 3: 358 ns per loop

In [3]: %timeit np.random.uniform([0], [1])
# this PR
100000 loops, best of 3: 4.95 µs per loop
# my changes
100000 loops, best of 3: 3.76 µs per loop

Not sure if the extra complexity is worth the gains, what do you think?

[gfyoung]

@jaimefrio : IMHO, simplicity wins in this case. It seems that the performance scales relatively well from the timing analysis you provided earlier, so obfuscating the code in order to optimize the smallest input case possible does not seem worthwhile here.

[jaimefrio]

If we go this route, I think we should move the array creation up, rather than redoing it:

olow = <ndarray>PyArray_FROM_OTF(low, NPY_DOUBLE, NPY_ARRAY_ALIGNED)
ohigh = <ndarray>PyArray_FROM_OTF(high, NPY_DOUBLE, NPY_ARRAY_ALIGNED)
if olow.shape == ohigh.shape == ():
    ...

It will make a noticeable difference if low and high are large arrays.

[gfyoung]

Ah, yes, good point. Done.

[homu]

☔ The latest upstream changes (presumably #7082) made this pull request unmergeable. Please resolve the merge conflicts.

[jaimefrio]

This is going to be painful to rebase, but once you get it done, it should be ready to go.

[gfyoung]

@jaimefrio : Rebase is done, and Travis + Appveyor are happy.

[gfyoung]

Accidentally clicked the wrong button when I wanted to comment. Whoops.

[jaimefrio]

Thanks Greg, one more in...

[gfyoung]

👍