[Numpy-discussion] nanargmax failure case (was: Re: [SciPy-Dev] 1.8.0rc1)

[Nathaniel Smith]

On Tue, Oct 1, 2013 at 9:37 PM,  <josef.pktd at gmail.com> wrote:
> Since numpy and scipy just moved to python 2.6, it's time to advertise
> and support
> warnings.catch_warnings().

warnings.catch_warnings is a very useful tool and this is all fun to
talk about, but realistically we're simply not going to merge any
change which involves telling people "the way you detect failure in
this function is to use the catch_warnings() context manager".

> If you want to wait for a "missing value support" in numpy to support
> this, then this postpones this to .... (numpy 3.0?)
> while gufuncs seem to be happening now.

No-one said anything about missing value support :-). I don't see how
it would really solve the problem -- we'll probably never allow
missing values to magically appear in arbitrary function outputs (e.g.
you can't put a bitpattern NA in a regular integer dtype, it's just
not possible).

On Tue, Oct 1, 2013 at 9:37 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> I'm surely not opposed to raising an exception if there is agreement on
> that. I think it would also be pretty easy to attach the result to the
> exception. For the latter it would be good to have an exception type that we
> could maybe reuse for other parts of Numpy.

It is true that no-one's ever objected to the ValueError that
nanarg{max,min} have raised in the past, right? That seems like one
measure of agreement that it's at least acceptable.

Spitball of a proper solution, though some thought would need to go
into how to get this out of gufuncs. (And absolutely unsuitable for
1.8!):

class VectorizedError(object):
    pass

def vectorized_raise(result, good_mask, exceptions):
    exc_types = set([type(e) for e in exceptions])
    exc_types.add(VectorizedError)
    exc_type = type.__new__(type, "SubVectorizedError", tuple(exc_types), {})
    exc = exc_type("