[Numpy-discussion] Solaris Sparc build broken

David Cournapeau cournape@gmail....
Thu Nov 12 16:56:09 CST 2009


On Thu, Nov 12, 2009 at 11:34 PM, Michael Droettboom <mdroe@stsci.edu> wrote:
> The new macros contain non-constant initializers for a type declared
> constant.
>
>    const union IEEEl2bitsrep u = {x};
>
> AFAIK, ANSI dictates that the initializer must be a literal or another
> constant variable.  We could declare 'x' as constant in the function
> signature, but it actually does get changed in the body of the function.

yep, the const should not have been set in the first place here.

> Hopefully a good compiler optimizer will alias this away.
> Alternatively, we could do what C++ would call a "reinterpret cast",
> which would avoid the need for the "do { ... } while (0);" trick:
>
>   ((IEEEl2bitsrep *)(&(x)))->a

Nope, this is not guaranteed to work, and is exactly what I am trying
to avoid with union :)

>
> Also, it seems LDBL_NBIT wasn't defined for the
> HAVE_LDOUBLE_IEEE_QUAD_BE case:
>
>   "numpy/core/src/npymath/ieee754.c.src", line 176: undefined symbol:
> LDBL_NBIT
>
> I defined it as 0.  Is that correct?

Yes.

>
> So that got it to compile.  Unfortunately, then I run into assertion
> errors in the unit test:
>
>  > /home/mdroe/numpy/numpy/core/tests/test_umath.py(834)test_nextafter()
> -> assert np.nextafter(one, two) - one == eps
> (Pdb) p t
> <type 'numpy.float128'>
> (Pdb) p eps
> 1.9259299443872358531e-34
> (Pdb) p np.nextafter(one, two)
> 1.0
> (Pdb) p np.nextafter(one, two) - one
> 0.0
> (Pdb) p (np.nextafter(one, two) - one) == 0.0
> True
>
> It looks as if the nextafterl implementation isn't ever packing fields
> back into the long double at all.  I can confirm this error even when
> using the numpy nextafterl on x86 Linux with gcc (by undef'ing
> HAVE_NEXTAFTERL on that platform).
>
> Take for example the following block:
>
>    if (x == 0.0) {
>        xmanh = 0;              /* return +-minsubnormal */
>        xmanl = 1;
>        xsign = ysign;
>        t = x * x;
>        if (t == x) {
>            return t;
>        } else {
>            return x;           /* raise underflow flag */
>        }
>    }
>
> 'xmanh', 'xmanl' and 'xsign' are completely disconnected variables from
> the original long double 'x'.

Yes, you're right, the current code does not make any sense. I don't
know what I was thinking (probably not much).

>  Personally,
> I think the getter/setter approach is cleaner, even if more verbose,
> because it's not otherwise terribly obvious when the value needs to be
> re-packed.

Yes, GETTER/SETTER is also more similar to the other cases
(single/double precision).

> I'm happy to make these changes, since I've got access to the "finicky"
> platform, but want to confirm how you would prefer it done first.

Cool. The changes should be done for all platforms, and pointer cast
should be done through union, not (*(new type*)(&x)).

thanks,

David


More information about the NumPy-Discussion mailing list