Off the cuff, my intuition is that dtypes will want to be able to
define how scalar indexing works, and let it return objects other than
arrays. So e.g.:
- some dtypes might just return a zero-d array
- some dtypes might want to return some arbitrary domain-appropriate
type, like a datetime dtype
On Sat, Feb 22, 2020 at 9:41 AM wrote:
>
>
> On Sat, Feb 22, 2020 at 9:34 AM wrote:
>
>> not having a hashable tuple conversion would be a strong limitation
>>
>> a = tuple(np.arange(5))
>> versus
>> a = tuple([np.array(i) for i in range(5)])
>> {a:5}
>>
>
> also there is the question of which
On Sat, Feb 22, 2020 at 9:34 AM wrote:
> not having a hashable tuple conversion would be a strong limitation
>
> a = tuple(np.arange(5))
> versus
> a = tuple([np.array(i) for i in range(5)])
> {a:5}
>
also there is the question of which scalar
.item() versus [()]
This was used in the old
not having a hashable tuple conversion would be a strong limitation
a = tuple(np.arange(5))
versus
a = tuple([np.array(i) for i in range(5)])
{a:5}
Josef
On Sat, Feb 22, 2020 at 9:28 AM Evgeni Burovski
wrote:
> Hi Sebastian,
>
> Just to clarify the difference:
>
> >>> x = np.float64(42)
> >>>
Hi Sebastian,
Just to clarify the difference:
>>> x = np.float64(42)
>>> y = np.array(42, dtype=float)
Here `x` is a scalar and `y` is a 0D array, correct?
If that's the case, not having the former would be very confusing for
users (at least, that would be very confusing to me, FWIW).
If
