[Numpy-discussion] Proposed Roadmap Overview

Ralf Gommers ralf.gommers@googlemail....
Sun Feb 19 04:03:15 CST 2012


On Sun, Feb 19, 2012 at 10:28 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:

> On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau <cournape@gmail.com>wrote:
>
>> On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe <mwwiebe@gmail.com> wrote:
>> > On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau <cournape@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
>> >> <charlesr.harris@gmail.com> wrote:
>> >>
>> >> >
>> >> > Well, we already have code obfuscation (DOUBLE_your_pleasure,
>> >> > FLOAT_your_boat), so we might as well let the compiler handle it.
>> >>
>> >> Yes, those are not great, but on the other hand, it is not that a
>> >> fundamental issue IMO.
>> >>
>> >> Iterators as we have it in NumPy is something that is clearly limited
>> >> by C. Writing the neighborhood iterator is the only case where I
>> >> really felt that C++ *could* be a significant improvement. I use
>> >> *could* because writing iterator in C++ is hard, and will be much
>> >> harder to read (I find both boost and STL - e.g. stlport -- iterators
>> >> to be close to write-only code). But there is the question on how you
>> >> can make C++-based iterators available in C. I would be interested in
>> >> a simple example of how this could be done, ignoring all the other
>> >> issues (portability, exception, etc…).
>> >>
>> >> The STL is also potentially compelling, but that's where we go into my
>> >> "beware of the dragons" area of C++. Portability loss, compilation
>> >> time increase and warts are significant there.
>> >> scipy.sparse.sparsetools has been a source of issues that was quite
>> >> high compared to its proportion of scipy amount code (we *do* have
>> >> some hard-won experience on C++-related issues).
>> >
>> >
>> > These standard library issues were definitely valid 10 years ago, but
>> all
>> > the major C++ compilers have great C++98 support now.
>>
>> STL varies significantly between platforms, I believe it is still the
>> case today. Do you know the status of the STL on bluegen, on small
>> devices ? We unfortunately cannot restrict ourselves to one well known
>> implementation (e.g. STLPort).
>
>
> Is there anyone who uses a blue gene or small device which needs
> up-to-date numpy support, that I could talk to directly? We really need a
> list of supported platforms on the numpy wiki we can refer to when
> discussing this stuff, it all seems very nebulous to me.
>

The list of officially supported platforms, where supported means we test
and release binaries if appropriate, is short: Windows, Linux, OS X.  There
are many platforms which are "supported" in the form of feedback on the
mailing list or Trac. This explanation is written down somewhere, not sure
where right now.

The best way to get an overview of those is to look at the distutils code
for various compilers, and at npy_cpu.h and similar. We're not talking
about expanding the number of officially supported platforms here, but not
breaking those unofficially supported ones (too badly). It's possible we
break those once in a while, which becomes apparent only when we get a
patch of a few lines long that fixes it. What should be avoided is that
those few-line patches have to turn into very large patches.

The most practical way to deal with this is probably to take two or three
non-standard platforms/compilers, set up a buildbot on them, and when
things break ensure that fixing it is not too hard.

>From recent history, I'd suggest AIX, an ARM device and a PathScale
compiler. But the limitation is probably finding someone willing to run a
buildbot.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120219/11d6afa4/attachment.html 


More information about the NumPy-Discussion mailing list