> This breaks the API, which is not good at all. Does anybody use the
> vector method the old API provided (i.e. supplying a vector as t1 and
> get the output over the whole vector?). What do you propose? Leave the
> old API? I could rename the eval to e.g. eval_single.
True, the API breaks-- but the API was both confusing (for my part I
thought it was a bug I'd found a workaround for) and undocumented (the
example in the docs didn't work, which is always discouraging when you're
trying to sort out what's going on).
My vote is that the proposed API change is one to the "correct" behaviour
(i.e. most like raw GSL), and qualifies as a two-for-one bugfix. Unless
someone's very, very unlucky, it's also likely to break code immediately
and be noisy about it.
Doug
--
Queen Mary College, University of London "Still creating worlds..
Mathematical Sciences, Astronomy Unit .. but now with an accent!"

Dear all,
please find the snapshot
http://pygsl.sf.net/pygsl-snapshot.tar.gz
I finally fixed the memory leak in odeiv.evolve.apply. Correctly the
interface of the "old" function is now found at evolve.apply_vector,
while a simple evolve_apply is now available as well.
This breaks the API, which is not good at all. Does anybody use the
vector method the old API provided (i.e. supplying a vector as t1 and
get the output over the whole vector?). What do you propose? Leave the
old API? I could rename the eval to e.g. eval_single.
I still have problems with some tests of rng. I do not yet understand
where they come from, because when I type the numbers in it works :-(.
Does anybody see problems with rng in everyday usage?
statistics.char uses NPY_BYTE as internal representation.
Sincerely yours
Pierre