Re: [boost] Re: Boost Mathematicians

From: Ralf W. Grosse-Kunstleve (rwgk_at_[hidden])
Date: 2004-07-07 08:19:16

--- David Abrahams <dave_at_[hidden]> wrote:
> Oh, I find it perfectly easy to grasp, at least in a general sense.
> Your're using an iterative method and you want to know when your
> solution is "good enough".  You've implemented a heuristic for
> deciding.  Right?

Yes! Although it is more a multi-trial/trial-and-error method than an iterative
method.

> What I don't understand in this is why the use of
> Python makes a crucial difference in this heuristic.

Because I could never have done what I did in the same amount of time if I had
tried it in C++. Python is simply unbeatable when it comes to programmer
efficiency. It might be intimately connected to how I work as a scientist,
though. Initially I often have only a vague idea of what will work and I have
to try many different approaches. C++ is too rigid to support this kind of
"scientific research" efficiently. But Python is not just good for rapid
prototyping and testing of ideas. Here comes the 90-10 rule again: in the end
there are many algorithms that I don't even have to reimplement in C++. So I
never have to spent the time typing in twice the amount of code, working around
compiler bugs as soon as I start using new features of the language or new
libraries, and I don't have to wait for 15 minutes once more until everything
is rebuilt after changing just two lines in a core part of the system. To back
this up with an example: yesterday our whole ~100k C++ lines package (plus
Boost) worked fine everywhere except for a SEGFAULT on one platform out of 13.
It took me three hours to find out that changing boost::python::extract<int> to
boost::python::extract<long> fixed the problem. This was in code that I was
using for years; the only thing I did was moving it wholesale to a different
extension module. There is no obvious explanation for the SEGFAULT because the
size of int and long are exactly the same on that platform (RH 7.3, gcc 2.96).
Something like this happens to me all the time and over the year the hours add
up to months worth of time. Frustrations like this *never* happen in Python.

It is only a couple of decades ago or so that people thought it is worth
writing machine code in the interest of runtime efficiency, and the people with
compiled code where thought of as the unmanly guys. These days I see myself one
level up. Compiled code vs. Python today is like machine code vs. compiled code
yesterday...

I guess I could go on and on about this and I'll soon be banned from this list.
:-)

To bring this back to where we started: if I have to go through the pains of
"dropping down" to C++ I don't care about the extra loop that I might have to
write. What I would love to have though is a generic way to return large arrays
from functions without the copy, or small ones without the dynamic memory
allocation overhead. Hence my proposal with the array<MemoryModel,
IndexingModel> where I can plug in the memory model that is best for a given
situation. As far as I can tell the world has been very busy with
IndexingModels calling them all kinds of things including Storage, but
MemoryModels as parameters have been largely neglected. To me it seems once
this problem is solved many things will fall nicely into place. Instead of
arguing about the best indexing model, just plug in your own. Inherit from the
existing and customize as necessary, freely combine with different memory
models as needed or even better, array<MemoryModel, IndexingModel,
AlgebraModel>, with different algebras as well. This would be a tool that I
could see as increasing my efficiency in using C++ -- when I have no choice.
:-)

Just my $10. I realize other people have other goals.

Ralf

                
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail