On Wed, Jul 14, 2010 at 6:03 AM, Sturla Molden <stu...@molden.no> wrote: >> On Tue, Jul 13, 2010 at 10:30 PM, Kurt Smith <kwmsm...@gmail.com> wrote: > >> as a minor note, blitz++ handles this with expression templates, > > Blitz++ do this just for arrays with fixed size at compile time. > > The gain from template meta-programming is almost amortized from better > C++ compilers. Today C++ compiler tend to produce better machine code than > anything else (C and Fortran included) on x86 and amd64. While when > blitz++ was written, they were slow bloatware generators that took a > 5x-10x performance hit compared with Fortran77. They don't do that > anymore. > > If you have Langtangen's book on "Python Scripting for Computational > Science", chapter 10.3 explains how to wrap NumPy arrays in a C++ class. > > C++ also support complex numbers in the class std::complex, and > std::vector works almost like a Python list. std::map can be used almost > like a dictionary. So yes, C++ should be preferred over C. But preferred > over Fortran 95? > > There are two issues I think: > > * C++ is very hard to use correctly, and can take 10 years to fully > master. I does not take that long to learn Fortran 95. > > * We have Python (or Cython) to do the non-numerical work. If we just want > to crunch numbers, there is nothing like Fortran.
In case I haven't said it: I'm intending to have weave.inline-like support for both inlined fortran (which will come first, since the functionality is already there in fwrap) and for inlined C. The inlined C will possibly have some sugar for array indexing syntax e.g., "arr[i,j]" in the inlined C code would be transformed to valid C. >From a developer & maintainer's perspective, having 'fortran inline' gives us 1st-class arrays for free in the inlined code which is a huge plus. There is no need for index overloading & the requisite maintenance of the support code. The expressiveness in the inlined fortran code for array expressions is pretty good, and you can stay in the flow of your numpy array code. It delegates to Fortran what it's good at doing, and reserves everything else for the Python level, like Sturla has pointed out. Many fortran compilers give us threaded array operations for free, too, which is very nice, as Sturla mentioned. I'm planning to leverage the infrastructure for 'fortran inline' to make the 'C inline' easier. > > So what about Cython? > > In my experience, I always have to resort to Fortran or C++. Cython cannot > use NumPy arrays efficiently as function arguments. That is a big show > stopper. Cython therefore degenerate to C (working with pointers instead > of arrays), and we could just as well have written C, which is what we > want to avoid. So that leaves us with C++ (wrapped NumPy arrays) or > Fortran 95. The other part of my GSoC last summer was improving buffer support in Cython as envisioned by Dag Sverre; the basic functionality is there in the kurt-gsoc branch and it is the first steps towards 1st-class arrays in the Cython language. I hope Dag & I can find some time to get it merged, but outside constraints have prevented it. Kurt _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
