Hi, Richard, these are interesting suggestions, I may explore them a bit.
I tried initially to make something that would be usable without too
much pain for small-to-medium problem, and that could be used, albeit
with a performance hit, for a larger problem; but I'm sure I am
nowhere near what could be achieved for a larger problem. On the other
hand, it's quite possible that evaluation of the derivative function
would dominate, so that the time spent in the actual RK code would be
negligible; in that case, this might already be as good as it needs to
be.
Purely for my own interest, I doubt whether I'll make this public
unless someone specifically asks, I'm playing with a code generator
from this, that will try to generate good code from these tables --
but it's C code so far, not haskell. This isn't really a practical
thing, if I needed the ultimate C routine, it would have already been
faster and simpler to just write it directly instead of the
code-generation stuff I've been doing, but hey...
Uwe
On 4/26/09, Richard O'Keefe
I was interested to see a Runge-Kutta package posted to this list recently, particularly as I have a fairly simple-minded non-adaptive RK "generator": an AWK script that takes a table and some optional stuff and spits out C. The Haskell package is, of course, a lot prettier than my AWK program, as well as offering some adaptive methods, which is important.
We can imagine a spectrum of RK packages:
(1) Higher order function taking some runtime parameters. That's what we got.
(2) The same specialised for a known table at compile time. Doable using the code that we were given plus SPECIALIZE pragmas. I don't how well that works across modules.
(3) A generator that writes Haskell source.
(4) Template Haskell.
(5) A generator that generates native code to be called through FFI.
The question is, how do you decide what's the appropriate approach?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe