On 10/16/06, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
The discussions of relax performance on relax-users
https://mail.gna.org/public/relax-users/2006-10/msg00024.html reminded
me of something I noticed recently and forgot to mention here. There are
several instances in relax where the apply() built-in function is used.
According to the Python Library Reference, apply(func, args, kwds) is
exactly equivalent to the extended call syntax: func(*args, **kwds). For
this reason apply has been deprecated since Python 2.3. In some very
quick and inexhaustive tests, I found replacing apply with func(*args,
**kwds) in relax to work, and indeed to give a significant performance
improvement (perhaps as much as 20%).
So, a couple of questions:
Is there a reason for sticking with the apply syntax that I've missed?
No. This is code from three years ago, back from the Python 2.2 days
and earlier. I wasn't aware that they had depreciated the function
and that the alternative method is faster.
Can we efficiently test the replacement to ensure no subtle breakages?
The apply functions are all in the 'minimise' directory. Each
optimisation algorithm (and the many subalgorithms, such as step
length selection techniques, etc.) calls the 'apply()' function. If
it can be shown once that the two different approaches return the same
result, then it should be fairly safe to change.
Edward, at some point you mentioned the idea of high-level testing based
on the extensive back-calculated data you have. How much work would be
involved in getting that going?
This may take a few days (assuming I can find a bit of spare time).
It took a while to find, but I think the reference you are talking
about is https://mail.gna.org/public/relax-devel/2006-08/msg00028.html
(Message-id: <7f080ed10608082153x233e158ci8a8dfe7383065241@xxxxxxxxxxxxxx>)
where I talked about Schurr's synthetic relaxation data which I have
reproduced. However I do have better synthetic data for these tests.
The data in the directory
'test_suite/data/model_free/S2_0.970_te_2048_Rex_0.149' is one such
test set. I have a few more as well which can be added to the test
suite.
Chris, would you like to make a branch of the 1.3 line to play around
with the replacement? If you have a very minimal data set using your
own data and show that the 1.3 line pre-branching and the modified 1.3
branch return exactly the same results when using Newton optimisation,
it should be fairly safe for a full migration (within the branch to
start with).
In the mean time I can put the synthetic back-calculated data into the
test suite of the 1.2 line. I could then create tests for all the
optimisation algorithm combinations (essentially a massive cut and
paste job with tiny modifications). This I could do for a number of
data test sets. And it could be done for all the model-free models to
be fully comprehensive. The test will then all be set up to pass i.e.
passing is not reliant on correct optimisation but on the quality of
the optimisers in the 1.2 line and the model-free function code, which
hopefully are all 100% bug free! For the model-free code this is
fairly safe, but there are a few optimisation algorithms I have not
fully tested (you would really need to know what you were doing to
actually use these). Once this is done, I will port all the changes
into the 1.3 line. Then, Chris, you can port the changes into your
1.3 branch. If they all pass then your branch can safely be ported
back into the 1.3 line. If we decide to, we could also easily port
the changes back into the 1.2 line. Although this chain of events
sounds complex, it isn't really. Chris, what do you think?
Edward
Re: apply