WISH: [option to] make np.floor(), np.ceil(), np.trunc() etc return arrays with dtype=int

[chatcannon]

I'm trying to plot two quantities against each other but they are sampled at different intervals.
I tried plt.plot(array1, array2[np.floor(array1time / array2interval)]).
However, np.floor returns a float array so I need to cast the result to an integer type first.

This seems a bit silly. Is there any reason why someone would depend on the result of floor() being a floating point number?

[charris]

I've had the same wish, although the difference between float and integer might be fishy for large numbers, we would probably want a range check and warning. The functions also mirror the corresponding C functions, so we would need new names. Maybe ifloor (Fortran), etc., even if that sounds like Apple diversifying into the home improvement market.

[chatcannon]

I should have RTFM'ed - turns out there is a dtype= parameter on all ufuncs (it's just not exposed in the docstring)
http://docs.scipy.org/doc/numpy/reference/ufuncs.html#optional-keyword-arguments
However, when I use it I get a deprecation warning
DeprecationWarning: Implicitly casting between incompatible kinds. In a future numpy release, this will raise an error. Use casting="unsafe" if this is intentional.
Presumably the code for functions that return integers should be tweaked so that asking for an integer return dtype is not considered an unsafe cast.

[charris]

In the development version I get

TypeError                                 Traceback (most recent call last)
/home/charris/<ipython-input-7-14749a58ef39> in <module>()
----> 1 floor(a, dtype=int64)

TypeError: No loop matching the specified signature was found for ufunc floor

Presumably this could be fixed by adding a couple of new loops.

[seberg]

I thought the dtype paramter forces the dtype on all of them (including input). What does get the result chatcannon says on the dev version is passing an integer array as out parameter, which leaves the casting to the ufunc buffering mechanism.

[charris]

@seberg dtype seems to cause the input array(s) to be cast before calling a loop and also uses that for the output. That isn't very memory efficient, it would actually be nice to, eg., add two integer arrays in a float accumulator in order to conserve memory. In any case, the result will be cast to the out dtype regardless of the value of dtype.

In [16]: out = array(1, dtype=int64)

In [17]: add(.5, .5, out=out)
Out[17]: array(1)

In [23]: add(.5, .5, out=out, dtype=float64)
Out[23]: array(1)

I don't think we have a way to tell numpy that it should take two float inputs and generate an integer output for functions like floor without using the out argument as there is no way to independently specify the output type of the function in the call. Some loop signatures just don't seem possible with the current dispatch machinery without using a different name for the function.

The current problem can be solved by implementing ifort etc. in python using the out argument. I wonder where such functions should go?

[charris]

I think things are as they should be, closing this.

[chatcannon]

Hang on a minute here.

There should be a way to call floor() etc on a float-type array and get an int-type return value, without any spurious warnings. Currently there isn't. Surely this is a bug or at least a missing feature?

[chatcannon]

P.S. I checked and I too get an error when calling floor(x, dtype=int), ceil(x, dtype=int) etc. The warning appears when calling np.floor_divide(x, y, dtype=int).

[charris]

You probably don't want to do that as the floats are converted to int by truncation before floor, etc., are applied.

[chatcannon]

OK then so my proposed solution doesn't work. There should still be a way of doing this - either by changing the semantics of the dtype keyword argument for these functions or by adding a new argument.

[seberg]

Well, you can do np.floor(a, out=np.empty_like(a, dtype=np.int_), casting='unsafe'). Pretty isn't it ;).

[dstansby]

Hello, I'm not sure why this was closed? There is currently no easy way to make np.ceil, np.floor etc. return an integer. I'm not sure why this is the case - surely by definition they should always return integers, therefore there is no reason returning them as floating point numbers.

I came across this because I use values calculated by np.ceil in indexing arrays, which now throws the warning:
VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future

[rkern]

They return values that are mathematical integers, but not necessarily ints (for any of the supported numpy integer dtypes). Also excepting NaNs and infs. The same logic that applies to C (e.g. floor(3)) applies here. Python only recently changed its related operations to return ints because it has arbitrary-precision integers and, only operating on one value at a time, can just raise an exception in the case of a nonfinite input.