Nice efforts! As is, I think what might work is if you create a special type resolver for it (there may already be one which does it also).

We could consider creating the special type resolver also, and give a FutureWarning that in the future it will not always cast to a floating value magically, but will also honor integer loops, etc.

I don't have the time right now, but if you can't find it, just make a note or I will probably forget to give more hints.

A bit of a look, it looks like you are on the right track. I would say that you can put it into a single loop if possible. Not sure about the error on first sight, it sounds a bit like it does not have an iii->i loop?

Thanks for your comments. I can replicate the previous type behaviour by creating a type resolver that forces the casting to be unsafe. I'm not sure how to introduce any warnings, because the type resolver doesn't seem to have access to the target array type, so the error can't be raised there.

I come across another problem:
The expected behaviour concerning NaN would be to propagate NaN for the first argument, but not for the min or max arguments. This can be easily implemented in the ufunc loops. However, the ufunc does not allow for variable arguments and neither fmin/fmax nor minimum/maximum allow for this asymmetrical NaN propagation. The only solution I can think of, would be to create two more ufunc that follow this behaviour, but that seems very inelegant.

Does anyone have any ideas how to address these issues? Thanks

There seems to be another NaN issue. On all but Travis build nr 5, it shows error:
RuntimeWarning: invalid value encountered in clip, which I managed to reproduce on Ubuntu 12.04, Python 2.7.3 with:
np.array([np.NaN]).clip(1,2)

However, when I change

NPY_NO_EXPORT void
@TYPE@_clip(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UNUSED(func))
{
    TERNARY_LOOP {
        const @type@ in = *((@type@ *)ip1);
        const @type@ min = *((@type@ *)ip2);
        const @type@ max = *((@type@ *)ip3);

        if (@lt@(in, min)) {
            *((@type@ *)op1) = min;
        }
        else if (@gt@(in, max)) {
            *((@type@ *)op1) = max;
        }
        else {
            *((@type@ *)op1) = in;
        }
    }
}

, which yields

>>> np.array([np.NaN]).clip(1,2)
__console__:1: RuntimeWarning: invalid value encountered in clip
array([ nan])

, to

NPY_NO_EXPORT void
@TYPE@_clip(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UNUSED(func))
{
    TERNARY_LOOP {
        const @type@ in = *((@type@ *)ip1);
        const @type@ min = *((@type@ *)ip2);
        const @type@ max = *((@type@ *)ip3);

        printf(in < min ? "a" : "b");
        printf(in > max ? "c" : "d");
        if (@lt@(in, min)) {
            *((@type@ *)op1) = min;
        }
        else if (@gt@(in, max)) {
            *((@type@ *)op1) = max;
        }
        else {
            *((@type@ *)op1) = in;
        }
    }
}

, it shows

>>> np.array([np.NaN]).clip(1,2)
bdarray([ nan])

Can anyone advise on what causes this? Thanks

Hmm, I don't really know floating point flag details. You could check for NaN first to avoid the flag being set probably, or possible unset the flag (@juliantaylor might know without thinking much).
Things changing with the prints, might be because of different vectorization or so, it is nothing unusual I think.

About giving a warning, one thing we did before was introduce special casting flag like "FORCE_CAST_BUT_WARN", it is a bit of a cludge, but works.

Could #5142 (behavior of clip when amin > amax) be fixed during this rewrite too? Just a suggestion from the peanut gallery :-)

☔ The latest upstream changes (presumably #8475) made this pull request unmergeable. Please resolve the merge conflicts.

Since homu mentioned it, looked at it again. In principle I still really like it, and I think the NaN problems can probably be gotten around (mostly) (on linux there is a comparison function which will not set the floating point error flags for example).

One problem I still see is that it seems that the clip function may allow for None to mean that no clipping should be done. Which is something that the ufunc cannot support (except by using the maximum value). Or maybe I am being silly and this is only true in the C-Api though....

If you ever pick it up again or decide its too complex, we can still warm up the old PR to just fix the out problem....

I'll take another look at this this weekend, see if I can finish it / make some progress.

@drumstok: Think you'll return to this, or do you want someone else to take over?

I have rebased and incorporated #8475 in the ufunc docstrings. However, having looked again at the work that still needs to be done, I am fine with someone taking over. The complications that arise from the NaN's and the allowing of missing arguments make this a bit too complicated for me at the moment. ( @eric-wieser )

Continued in #12519

I guess we can close it for now then in favor of the new approach. The 3 ufunc approach seems more realistic anyway.

Thanks all!