<br><br><div class="gmail_quote">On Sun, Feb 19, 2012 at 10:28 AM, Mark Wiebe <span dir="ltr">&lt;<a href="mailto:mwwiebe@gmail.com">mwwiebe@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div class="h5">On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau <span dir="ltr">&lt;<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div>On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe &lt;<a href="mailto:mwwiebe@gmail.com" target="_blank">mwwiebe@gmail.com</a>&gt; wrote:<br>
&gt; On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau &lt;<a href="mailto:cournape@gmail.com" target="_blank">cournape@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris<br>
&gt;&gt; &lt;<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Well, we already have code obfuscation (DOUBLE_your_pleasure,<br>
&gt;&gt; &gt; FLOAT_your_boat), so we might as well let the compiler handle it.<br>
&gt;&gt;<br>
&gt;&gt; Yes, those are not great, but on the other hand, it is not that a<br>
&gt;&gt; fundamental issue IMO.<br>
&gt;&gt;<br>
&gt;&gt; Iterators as we have it in NumPy is something that is clearly limited<br>
&gt;&gt; by C. Writing the neighborhood iterator is the only case where I<br>
&gt;&gt; really felt that C++ *could* be a significant improvement. I use<br>
&gt;&gt; *could* because writing iterator in C++ is hard, and will be much<br>
&gt;&gt; harder to read (I find both boost and STL - e.g. stlport -- iterators<br>
&gt;&gt; to be close to write-only code). But there is the question on how you<br>
&gt;&gt; can make C++-based iterators available in C. I would be interested in<br>
&gt;&gt; a simple example of how this could be done, ignoring all the other<br>
&gt;&gt; issues (portability, exception, etc…).<br>
&gt;&gt;<br>
&gt;&gt; The STL is also potentially compelling, but that&#39;s where we go into my<br>
&gt;&gt; &quot;beware of the dragons&quot; area of C++. Portability loss, compilation<br>
&gt;&gt; time increase and warts are significant there.<br>
&gt;&gt; scipy.sparse.sparsetools has been a source of issues that was quite<br>
&gt;&gt; high compared to its proportion of scipy amount code (we *do* have<br>
&gt;&gt; some hard-won experience on C++-related issues).<br>
&gt;<br>
&gt;<br>
&gt; These standard library issues were definitely valid 10 years ago, but all<br>
&gt; the major C++ compilers have great C++98 support now.<br>
<br>
</div></div>STL varies significantly between platforms, I believe it is still the<br>
case today. Do you know the status of the STL on bluegen, on small<br>
devices ? We unfortunately cannot restrict ourselves to one well known<br>
implementation (e.g. STLPort).</blockquote><div><br></div></div></div><div>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.</div>
</div></blockquote><div><br>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 &quot;supported&quot; in the form of feedback on the mailing list or Trac. This explanation is written down somewhere, not sure where right now. <br>
<br>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&#39;re not talking about expanding the number of officially supported platforms here, but not breaking those unofficially supported ones (too badly). It&#39;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.<br>
<br>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.<br><br>From recent history, I&#39;d suggest AIX, an ARM device and a PathScale compiler. But the limitation is probably finding someone willing to run a buildbot.<br>
<br>Ralf<br></div></div>