[Numpy-discussion] Proposed Roadmap Overview

[Mark Wiebe]

On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau <cournape at gmail.com>wrote:

> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
> <charlesr.harris at 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. Is there a specific
target platform/compiler combination you're thinking of where we can do
tests on this? I don't believe the compile times are as bad as many people
suspect, can you give some simple examples of things we might do in NumPy
you expect to compile slower in C++ vs C?

-Mark


> >
> > Jim Hugunin was a keynote speaker at one of the scipy conventions. At
> dinner
> > he said that if he was to do it again he would use managed code ;) I
> don't
> > propose we do that, but tools do advance.
>
> In an ideal world, we would have a better language than C++ that can
> be spit out as C for portability. I have looked for a way to do this
> for as long as I have been contributing to NumPy (I have looked at
> ooc, D, coccinelle at various stages). I believe the best way is
> actually in the vein of FFTW: written in a very high level language
> (OCAML) for the hard part, and spitting out C. This is better than C++
> is many ways - this is also clearly not realistic :)
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120219/0ba6b5ea/attachment.html>