[Numpy-discussion] numpy.floor() is supposed to return an int, but returns a float

[Tim Hochberg]

Tim Hochberg wrote:

> Webb Sprague wrote:
>
>> I think the docstring implies that numpy.floor() returns an integer
>> value. 
>
> You've been programming to much!
>
> Everywhere but the computer programming world, 1.0 is integer.  Even 
> their, many (most?) computer languages avoid the term integer using 
> int, Int or something similar. The distinction made between ints and 
> integral floating point values is mostly an artificial one resulting 
> from implementation issues. Making this distinction is also a handy, 
> if imperfect,  proxy for exact / versus inexact numbers.
>
>> One can cast the float value to a usable integer value, but
>> either the docstring should read something different or the function
>> should be changed (my preference).
>>
>> "y = floor(x) elementwise largest integer <= x" is the docstring.
>

Let me just add that, since this seems to cause confusion, it would be 
appropriate to amend the docstring tobe explicit that this always 
returns an integral floating point value. If someone wants to suggest 
wording, I can figure out where to put it. One possibility is:

    "y = floor(x) elementwise largest integer <= x; note that the result 
is a floating point value"

or

    "y = floor(x) elementwise largest integral float <= x"


Neither of those is great, but perhaps they'll inspire someone to do better.

-tim

>>
>> As far as "integral valued float" versus "integer", this distinction
>> seems a little obscure...
>>
> An integral floating point value *is* an integer, just ask any 12 year 
> old. What's obscure is the way concepts of integers and reals get 
> mapped to ints and floats. Don't get me wrong, these are reasonable 
> comprises given the sad reality that computers are not so hot at 
> representing inifinte quantities.  However, we get sucked into 
> thinking that integers and ints are really the same things at our 
> peril. Similarly for floats and reals.
>
>>  I am sure the difference is very important
>> in some contexts, but I for one think that floor should return a
>> straight up integer,
>>
> It's a ufunc. Ufuncs in general return the same type that they operate 
> on. So, not only would this be difficult, it would make the signature 
> of ufuncs harder to remember.
>
> Also, as Robert Kern just pointed out, not all intergral FP values can 
> be represents as ints.
>
>> if just for code style (see example below). Plus
>> it will be upcast to a float whenever necessary, so floor(4.5) + .75
>> == 4.75 whether floor() returns an int or a float.
>>  
>>
>    Not every two-line Python function has to come pre-written -- Tim 
> Peters on C.L.P
>
> def webbsfloor(x):
>    return numpy.floor(x).astype(int)
>
>> fooMatrix[numpy.floor(age/ageWidth)]
>>
>> is better (easier to type, read, and debug) than
>>
>> fooMatrix[numpy.floor(age/ageWidth).astype(int)]
>>
>> If there is a explanation as to why an integral valued float is a
>> better return value, I would be interested in a link.
>>  
>>
> I think there's at least four reasons:
>
> 1. It would be a pain.
> 2. It would make the ufuncs inconsistent.
> 3. It's a thin wrapper over C's floor, so people coming from that 
> language be confused.
> 4. It wouldn't work for numbers with very large magnitudes.
>
> Pick any three
>
>
> Regards,
>
> -tim
>