[Numpy-discussion] Proposed Roadmap Overview
Sat Feb 18 16:24:33 CST 2012
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
> 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).
> 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 :)
More information about the NumPy-Discussion