<div class="gmail_quote">On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau <span dir="ltr">&lt;<a href="mailto:cournape@gmail.com">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 class="HOEnZb"><div class="h5">On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe &lt;<a href="mailto:mwwiebe@gmail.com">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">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">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>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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
&gt; Is there a specific<br>
&gt; target platform/compiler combination you&#39;re thinking of where we can do<br>
&gt; tests on this? I don&#39;t believe the compile times are as bad as many people<br>
&gt; suspect, can you give some simple examples of things we might do in NumPy<br>
&gt; you expect to compile slower in C++ vs C?<br>
<br>
</div>Switching from gcc to g++ on the same codebase should not change much<br>
compilation times. We should test, but that&#39;s not what worries me.<br>
What worries me is when we start using C++ specific code, STL and co.<br>
Today, scipy.sparse.sparsetools takes half of the build time  of the<br>
whole scipy, and it does not even use fancy features. It also takes Gb<br>
of ram when building in parallel.<br></blockquote><div><br></div><div>Particular styles of using templates can cause this, yes. To properly do this kind of advanced C++ library work, it&#39;s important to think about the big-O notation behavior of your template instantiations, not just the big-O notation of run-time. C++ templates have a turing-complete language (which is said to be quite similar to haskell, but spelled vastly different) running at compile time in them. This is what gives template meta-programming in C++ great power, but since templates weren&#39;t designed for this style of programming originally, template meta-programming is not very easy.</div>
<div><br></div><div>Cheers,</div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
David<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br>