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