Charles R Harris wrote: > > > On Thu, Nov 5, 2009 at 10:35 PM, David Cournapeau > <[email protected] <mailto:[email protected]>> > wrote: > > Charles R Harris wrote: > > So you are going to leave us all hanging here in curiosity? What is > > your solution? > > I had to sleep :) > > The solution is based on parsing the generated binary code - > that's how > MPFR is doing it, so it has been tested in the wild. The code to > compile > is something like: > > /* "before" is 16 bytes to ensure there's no padding between it > and "x". > * We're not expecting any "long double" bigger than 16 bytes > or with > * alignment requirements stricter than 16 bytes. */ > typedef long double test_type; > > struct { > char before[16]; > test_type x; > char after[8]; > } foo = { > { '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0', > '\001', '\043', '\105', '\147', '\211', '\253', '\315', > '\357' }, > -123456789.0, > { '\376', '\334', '\272', '\230', '\166', '\124', '\062', > '\020' } > }; > > They compile it, parse with awk from the dump od -f. > > > So the before/after bits are tags that mark the beginning/end of the > type for the parse? Any particular reason not to use a string? As for why not using my name, I am not that megalomaniac, at least not yet :)
od prints a dump in octal form, so a string is not much more readable. I am not sure why they use od instead of another dump format - but there is value if keeping the same format as them for testing, all other things being equal. Anyway, the detection code is checked in in svn now, I just need to fix universal build issue, but this should not be difficult, David _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
