The substitution principle is interesting (and, being trained as an
astronomer, not a computer scientist, I had not heard of it before). I
think matrix is indeed obviously wrong here (with indexing being more
annoying, but multiplication being a good example as well).
Perhaps more interesting as a
>
> I don't think so. Dtypes have nothing to do with a whole set of use cases
> that add extra methods or attributes. Random made-up example: user has a
> system with 1000 sensor signals, some of which should be treated with
> robust statistics for . So user writes a
> subclass robust_ndarray, adds
On Tue, Oct 30, 2018 at 2:22 PM Stephan Hoyer wrote:
> On Mon, Oct 29, 2018 at 9:49 PM Eric Wieser
> wrote:
>
>> The latter - changing the behavior of multiplication breaks the principle.
>>
>> But this is not the main reason for deprecating matrix - almost all of
>> the problems I’ve seen have
Would the extended dtypes also violate the Liskov substitution principle?
In place operations which would mutate the dtype are one potential issue.
Would a single dtype for an array be sufficient, i.e. np.polynomial
coefficients? Compared to ndarray subclasses, the memory layout issue goes
away, b
On Tue, Oct 30, 2018 at 2:22 PM, Stephan Hoyer wrote:
> The Liskov substitution principle (LSP) suggests that the set of
> reasonable ndarray subclasses are exactly those that could also in
> principle correspond to a new dtype. Of np.ndarray subclasses in
> wide-spread use, I think only the vari
On Mon, Oct 29, 2018 at 9:49 PM Eric Wieser
wrote:
> The latter - changing the behavior of multiplication breaks the principle.
>
> But this is not the main reason for deprecating matrix - almost all of the
> problems I’ve seen have been caused by the way that matrices behave when
> sliced. The w
On Tue, Oct 30, 2018 at 12:49 AM Eric Wieser
wrote:
> The latter - changing the behavior of multiplication breaks the principle.
>
> But this is not the main reason for deprecating matrix - almost all of the
> problems I’ve seen have been caused by the way that matrices behave when
> sliced. The
The latter - changing the behavior of multiplication breaks the principle.
But this is not the main reason for deprecating matrix - almost all of the
problems I’ve seen have been caused by the way that matrices behave when
sliced. The way that m[i][j] and m[i,j] are different is just one example
o
On Mon, Oct 29, 2018 at 4:31 PM Chris Barker wrote:
> On Fri, Oct 26, 2018 at 7:12 PM, Travis Oliphant
> wrote:
>
>
>> agree that we can stop bashing subclasses in general. The problem with
>> numpy subclasses is that they were made without adherence to SOLID:
>> https://en.wikipedia.org/wiki
On Fri, Oct 26, 2018 at 7:12 PM, Travis Oliphant
wrote:
> agree that we can stop bashing subclasses in general. The problem with
> numpy subclasses is that they were made without adherence to SOLID:
> https://en.wikipedia.org/wiki/SOLID. In particular the Liskov
> substitution principle: ht
On Fri, Oct 19, 2018 at 8:24 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> It seems there are two extreme possibilities for general functions:
> 1. Put `asarray` everywhere. The main benefit that I can see is that even
> if people put in list instead of arrays, one is gu
On Fri, Oct 19, 2018 at 6:23 PM, Marten van Kerkwijk
wrote:
> Hi All,
>
> It seems there are two extreme possibilities for general functions:
> 1. Put `asarray` everywhere. The main benefit that I can see is that even if
> people put in list instead of arrays, one is guaranteed to have shape,
> dt
On Fri, Oct 19, 2018 at 7:00 PM, Charles R Harris
wrote:
>
> On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser
> wrote:
>>
>> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
>> they cause problems perhaps that should be seen as a sign that ndarray
>> subclassing should be mad
On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser
wrote:
> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
> they cause problems perhaps that should be seen as a sign that ndarray
> subclassing should be made easier and clearer.
>
> Both maskedarray and quantity seem like som
Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
they cause problems perhaps that should be seen as a sign that ndarray
subclassing should be made easier and clearer.
Both maskedarray and quantity seem like something that would make more
sense at the dtype level if our dt
Hi All,
It seems there are two extreme possibilities for general functions:
1. Put `asarray` everywhere. The main benefit that I can see is that even
if people put in list instead of arrays, one is guaranteed to have shape,
dtype, etc. But it seems a bit like calling `int` on everything that might
On Fri, Oct 19, 2018 at 10:28 PM Ralf Gommers
wrote:
>
>
> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
> wrote:
>
>> Hi!
>>
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unle
>
> I think we should “soft support” i.e. allow but consider unsupported, the
>> case where one of NumPy’s functions is implemented in terms of others and
>> “passing through” an array results in the correct behaviour for that array.
>>
>
> I don't think we have or want such a concept as "soft supp
On Fri, Oct 19, 2018 at 3:28 PM, Ralf Gommers
wrote:
>
>
> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
> wrote:
>
>> Hi!
>>
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unle
On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
wrote:
> Hi!
>
> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
> wrote:
> I don't think it makes much sense to change NumPy's existing usage of
> asarray() to asanyarray() unless we add subok=True arguments (which default
> to False). But this en
Hi!
> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote:
> I don't think it makes much sense to change NumPy's existing usage of
> asarray() to asanyarray() unless we add subok=True arguments (which default
> to False). But this ends up cluttering NumPy's public
I don't think it makes much sense to change NumPy's existing usage of
asarray() to asanyarray() unless we add subok=True arguments (which default
to False). But this ends up cluttering NumPy's public API, which is also
undesirable. The preferred way to override NumPy functions going forward
should
There are exceptions for `matrix` in quite a few places, and there now is
warning for `maxtrix` - it might not be bad to use `asanyarray` and add an
exception for `maxtrix`. Indeed, I quite like the suggestion by Eric Wieser
to just add the exception to `asanyarray` itself - that way when matrix is
Hi all
> On Friday, Oct 19, 2018 at 10:28 AM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote:
>
> Was there discussion around which of `asarray` or asanyarray` to prefer? PR
> 11162, https://github.com/numpy/numpy/pull/11162, proposes `asanyarray` in
> place of `asarray` at the entrance to `
Was there discussion around which of `asarray` or asanyarray` to
prefer? PR 11162, https://github.com/numpy/numpy/pull/11162,
proposes `asanyarray` in place of `asarray` at the entrance to `_quantile_ureduce_func` to preserve ndarray
subclasses. Should we be looking
25 matches
Mail list logo
