[Numpy-discussion] floats for indexing, reshape - too strict ?

Jeff Reback jeffreback at gmail.com
Thu Jul 2 21:28:11 EDT 2015


FYI pandas followed the same pattern to deprecate float indexers (except for indexing in a Float64Index) about a year ago

see here: http://pandas.pydata.org/pandas-docs/stable/whatsnew.html#whatsnew-0140-deprecations

> On Jul 2, 2015, at 9:18 PM, <josef.pktd at gmail.com> <josef.pktd at gmail.com> wrote:
> 
> 
> 
>> On Thu, Jul 2, 2015 at 8:51 PM, Chris Barker - NOAA Federal <chris.barker at noaa.gov> wrote:
>> Sent from my iPhone
>> 
>> >
>> > The disadvantage I see is, that some weirder calculations would possible
>> > work most of the times, but not always,
>> 
>> 
>> >  not sure if you can define a "tolerance"
>> > reasonable here unless it is exact.
>> 
>> You could use a relative tolerance, but you'd still have to set that.
>> Better to put that decision squarely in the user's hands.
>> 
>> > Though I guess you are right that
>> > `//` will also just round silently already.
>> 
>> Yes, but if it's in the user's code, it should be obvious -- and then
>> the user can choose to round, or floor, or ceiling....
> 
> round, floor, ceil don't produce integers.
> 
> I'm writing library code, and I don't have control over what everyone does.
> 
> round, floor, ceil, and // might hide bugs or user mistakes, if we are supposed to get something that is "like an int" but it's. 42.6 instead.
> 
> Josef
> https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life.2C_the_Universe.2C_and_Everything_.2842.29
> 
>  
>> 
>> -CHB
>> 
>> >
>> > - Sebastian
>> >
>> >>
>> >> for example
>> >>
>> >>
>> >>>>> 5.0 == 5
>> >> True
>> >>
>> >>
>> >>>>> np.ones(10 / 2)
>> >> array([ 1.,  1.,  1.,  1.,  1.])
>> >>>>> 10 / 2 == 5
>> >> True
>> >>
>> >>
>> >> or the python 2 version
>> >>
>> >>
>> >>>>> np.ones(10. / 2)
>> >> array([ 1.,  1.,  1.,  1.,  1.])
>> >>>>> 10. / 2 == 5
>> >> True
>> >>
>> >>
>> >> I'm using now 10 // 2, or int(10./2 + 1)   but this is unconditional
>> >> and doesn't raise if the numbers are not close or equal to an integer
>> >> (which would be a bug)
>> >>
>> >>
>> >>
>> >>
>> >> Josef
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> NumPy-Discussion mailing list
>> >> NumPy-Discussion at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> >
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > NumPy-Discussion at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150702/7bc82110/attachment.html>


More information about the NumPy-Discussion mailing list