[Numpy-discussion] Solaris Sparc build broken

Charles R Harris charlesr.harris at gmail.com
Fri Nov 6 12:28:49 EST 2009


On Fri, Nov 6, 2009 at 10:16 AM, David Cournapeau <cournape at gmail.com>wrote:

> On Sat, Nov 7, 2009 at 2:10 AM, David Cournapeau <cournape at gmail.com>
> wrote:
> > On Sat, Nov 7, 2009 at 12:05 AM, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >>
> >>
> >> On Fri, Nov 6, 2009 at 12:10 AM, David Cournapeau
> >> <david at ar.media.kyoto-u.ac.jp> wrote:
> >>>
> >>> Charles R Harris wrote:
> >>> >
> >>> >
> >>> > On Thu, Nov 5, 2009 at 10:35 PM, David Cournapeau
> >>> > <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
> >>> > 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.
> >>>
> >>
> >> Is od available on all platforms? Couldn't you just read the file using
> >> Python?
> >
> > That's actually what I have done. I am pretty sure windows does not
> > had od, for once :)
>
> the implementation is here if you want to look at it:
>
> http://svn.scipy.org/svn/numpy/trunk/numpy/core/setup_common.py
>
> The code for pyod is ugly, there are wasteful back and forth
> conversions, but it works, so..
>
>
I already looked at that commit. That's kind of a neat hack. I take it that
there is no platform out there at the moment that has big endian ieee
extended doubles? And if not now, probably never. I expect the same trick
would detect PPC also, although that probably isn't necessary.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091106/0d875ab6/attachment.html>


More information about the NumPy-Discussion mailing list