This change looks good to me.

If there are still lots of places in the code that are using invalid macros, maybe we should just run a global copy/replace now while we're thinking about it?

Looks good to me also. The unprefixed macro should be put into the noprefix.h header. You can probably look for other spots using a modification of the replace_old_macros.sed script in tools/ I run those scripts with find. There are lot of files to look at...

@certik These sort of fixes probably need a back port as 1.7 is supposed to be 'macro clean' and clearly there are some subtle problems that can appear when that isn't done. But I hate to suggest such intrusive changes after the first rc.

On a different note though, maybe someone can just tell me that this is actually plausible:

In [7]: def tohex(num, swap=False):
    return '-'.join(c.encode('hex') for c in (num if not swap else num.byteswap()).tostring()[::1 if swap else -1])
   ...: 

In [8]: tohex(np.float128(1))
Out[8]: '83-00-01-83-00-00-3f-ff-80-00-00-00-00-00-00-00'

In [9]: tohex(np.float128(1))
Out[9]: '00-00-00-00-03-74-3f-ff-80-00-00-00-00-00-00-00'

the underlying data is different, but even when double checking the value is identical also == works, so I guess maybe my float128 is not a real float128? Of course the 3f-ff and some more seem to be always there.

Intel long doubles are 96 bits padded to 128 bit alignment, so it's
possible that what you're seeing are differences in the contents of the
padding. (Not sure which bits are ignored.)
On 5 Jan 2013 15:43, "seberg" [email protected] wrote:

On a different note though, maybe someone can just tell me that this is
actually plausible:

In [7]: def tohex(num, swap=False):
return '-'.join(c.encode('hex') for c in (num if not swap else num.byteswap()).tostring()[::1 if swap else -1])
...:
In [8]: tohex(np.float128(1))Out[8]: '83-00-01-83-00-00-3f-ff-80-00-00-00-00-00-00-00'
In [9]: tohex(np.float128(1))Out[9]: '00-00-00-00-03-74-3f-ff-80-00-00-00-00-00-00-00'

the underlying data is different, but even when double checking the value
is identical also == works, so I guess maybe my float128 is not a real
float128? Of course the 3f-ff and some more seem to be always there.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2886#issuecomment-11915405.

This shows some more

charris@f16 [numpy.git (master)]$ grep -r '[^_]SIZEOF_' numpy/

@seberg Do you want to make those fixes or should I?

Please go ahead, this macro stuff is confusing me anyway...

During a cleanup, the fast paths were invalidated because SIZEOF_LONGDOUBLE
was not defined anymore and needs to be replaced with NPY_SIZEOF_LONGDOUBLE.
The other SIZEOF macros still existed however so only complex long double
broke because it switched to the already broken fast path.

I don't understand the paragraph. So SIZEOF_LONGDOUBLE is still defined, and that's the reason why the old code compiled, correct? What is the difference between NPY_SIZEOF_LONGDOUBLE and SIZEOF_LONGDOUBLE?

@charris, the change looks ok to me, I only have one question above in the test ("c8"...) and then about the macros in my previous comment. After I understand the answers to those two questions, I'll see if we should backport it.

I may have misinterpreted it (I don't know macro stuff), but my guess was, it is not defined anymore, but since it was only inside an #if ... preprocessor statement that statement that #if simply evaluated false dropping through to the general not unrolled for loop case (which was buggy prior to this, but since no compiler has a floating with more then 16 bytes it never mattered).

Ah, I see how it works. Yes, in this case I think we should backport it. @charris, @njsmith, let me know if you agree.

@certik: Are you planning to do an rc2?

@certik None of the uprefixed macros are defined for numpy sources, so any use of them is inviting a bug. Or may expose bugs ;) As Sebastian has pointed out, the compiler will not raise any errors if an undefined macro is used in a logic statement, it just evaluates to false. We will need to do another release candidate though.

@njsmith, I was planning to just do the final release, but given this, I can do rc2. It's not a problem at all --- I have it all scripted now. I am now updating my Fabric fab files for Mac, so that they are fully automated too. So either is fine with me.

Yeah, I guess it's a good idea to both backport those and do an rc2 then.

OK.