Oh sorry. That's trigger finger np-dotting.
What i mean is if someone was using the round method on float32 or other
small bit datatypes they would have a silent upcasting.
Maybe not a big problem but can have significant impact.
On Thu, Feb 27, 2020, 05:12 Robert Kern wrote:
> Your example
Our collaboration with the students and faculty from the Master’s program
in Survey Methodology at the University of Michigan and the University of
Maryland at College Park is underway. We are looking for a volunteer to
translate the survey questionnaire into Hindi. If you are available, or you
Your example used np.round(), not the builtin round(). np.round() is not
changing. If you want the dtype of the output to be the dtype of the input,
you can certainly keep using np.round() (or its canonical spelling,
np.around()).
On Thu, Feb 27, 2020, 12:05 AM Ilhan Polat wrote:
> It's not
It's not about what I want but this changes the output of round. In my
example I didn't use any arrays but a scalar type which looks like will
upcasted.
On Wed, Feb 26, 2020, 23:04 Robert Kern wrote:
> On Wed, Feb 26, 2020 at 5:41 PM wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 5:30 PM Ilhan
On Wed, Feb 26, 2020 at 6:59 PM wrote:
>
>
> On Wed, Feb 26, 2020 at 6:09 PM Robert Kern wrote:
>
>> On Wed, Feb 26, 2020 at 5:27 PM wrote:
>>
>>> great another object array
>>>
>>> np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20,
>>> 2e200])])
>>> array([1, 2,
On Wed, Feb 26, 2020 at 6:57 PM wrote:
>
>
> On Wed, Feb 26, 2020 at 6:09 PM Robert Kern wrote:
>
>> On Wed, Feb 26, 2020 at 5:27 PM wrote:
>>
>>> great another object array
>>>
>>> np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20,
>>> 2e200])])
>>> array([1, 2,
On Wed, Feb 26, 2020 at 6:09 PM Robert Kern wrote:
> On Wed, Feb 26, 2020 at 5:27 PM wrote:
>
>> great another object array
>>
>> np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20, 2e200])])
>> array([1, 2, 2,
>>
>>
>>
On Wed, Feb 26, 2020 at 5:27 PM wrote:
> great another object array
>
> np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20, 2e200])])
> array([1, 2, 2,
>
>
>
On Wed, Feb 26, 2020 at 5:30 PM Ilhan Polat wrote:
> Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int?
>
No. np.round() is an alias (which would be good to deprecate) for
np.around(). No one has proposed changing np.around().
> That would be really awkward for many
On Wed, Feb 26, 2020 at 5:41 PM wrote:
>
>
> On Wed, Feb 26, 2020 at 5:30 PM Ilhan Polat wrote:
>
>> Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int?
>>
>> That would be really awkward for many reasons pandas frame size being
>> bloated just by rounding for an example.
On Wed, Feb 26, 2020 at 5:30 PM Ilhan Polat wrote:
> Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int?
>
> That would be really awkward for many reasons pandas frame size being
> bloated just by rounding for an example. Or numpy array size growing for no
> apparent reason
Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int?
That would be really awkward for many reasons pandas frame size being
bloated just by rounding for an example. Or numpy array size growing for no
apparent reason
I am not really sure if I understand why LSP should hold in
great another object array
np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20, 2e200])])
array([1, 2, 2,
On Wed, Feb 26, 2020 at 3:19 PM Hameer Abbasi
wrote:
>
> There still remains the question, do we return Python ints or np.int64s?
>
>- Python ints have the advantage of not overflowing.
>- If we decide to add __round__ to arrays in the future, Python ints
>may become inconsistent
Hello,
Currently, the built-in Python round (which is different from np.round) when
called on a np.float64 returns a np.float64, due to its __round__ method. A
congruous statement is true for np.float32. However, since Python 3, the
default behavior of round is to return a Python int when it
15 matches
Mail list logo
