On Thu, Nov 12, 2009 at 11:34 PM, Michael Droettboom <[email protected]> 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
_______________________________________________
NumPy-Discussion mailing list
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
