Re: [Numpy-discussion] x.min() depends on ordering

[Charles R H. <cha...@gm...>]

On 11/11/06, Charles R Harris <cha...@gm...> wrote:
>
>
>
> On 11/11/06, Tim Hochberg <tim...@ie...> wrote:
> >
> > Robert Kern wrote:
>
>
> <snip>
>
> My preference would be to raise an error / warning when there is a nan
> > in the array. Technically, there is no minimum value when a nan is
> > present. I believe that this would be feasible be swapping the compare
> > from 'a < b' to '!(a >= b)'. This should return NaN if any NaNs are
> > present and I suspect the extra '!' will have minimal performance impact
> > but it would have to be tested. Then a warning or error could be issued
> > on the way out depending on the erstate. Arguably returning NaN is more
> > correct than returning the smallest non NaN anyway.
> >
>
> No telling what compiler optimizations might do with  '!(a >= b)' if they
> assume that '!(a >= b)' == 'a < b'. For instance,
>
> if !(a >= b)
>     do something;
> else
>     do otherwise;
>

This made me curious. Here is the code

int test(double a, double b)
{
    if (a > b)
        return 0;
    return 1;
}

Here is the relevant part of the assembly code when compiled with no
optimizations

        fucompp
        fnstsw  %ax
        sahf
        ja      .L4
        jmp     .L2
.L4:
        movl    $0, -20(%ebp)
        jmp     .L5
.L2:
        movl    $1, -20(%ebp)
.L5:
        movl    -20(%ebp), %eax
        leave
        ret

Which jumps to the right place on a > b (ja)

Here is the relevant part of the assembly code when compiled with -O3

        fucompp
        fnstsw  %ax
        popl    %ebp
        sahf
        setbe   %al
        movzbl  %al, %eax
        ret

Which sets the value of the return to the logical value of a <= b (setbe),
which won't work right with NaNs. Maybe the compiler needs another flag to
deal with the possibility of NaN's because the generated code is actually
incorrect. Or maybe I just discovered a compiler bug. But boy, that compiler
is awesome clever. Those optimizers are getting better all the time.

Chuck