Re: r24983 - in /branches/R1_fitting: specific_analyses/relax_disp/ test_suite/unit_tests/_specific_analyses/_relax_disp/ -- August 18, 2014 - 16:41

Hi Edward.

The good thing about the code, is that a change for the nesting only
needs very little work.
Only one or two lines needs to be changed. That is all.

It became a realisation for me, that when adding new models to relax,
it should not be necessary to
hard code every possibility into relax in the auto analysis.

There have to be a function helping out with this.

I can write up some examples, which illustrate the problem.

CPMG:
models = ['R2eff', 'No Rex', 'B14', 'NS CPMG 2-site 3D', 'NS CPMG
2-site expanded']

This would for the user seem to be a good list of models to test.
The user have maybe read, that 'B14' is more precise than 'CR72', and
does not wan't "waste" time on CR72.

But nothing would be nested, even though that the solutions should be
expected to be quite similar.
Why not nest from 'B14'? or 'NS CPMG 2-site 3D', if the optimised
parameters are there?

models = ['R2eff', 'No Rex', 'CR72', 'B14', 'NS CPMG 2-site 3D', 'NS
CPMG 2-site expanded']
Here the user "knows", that it is essential to nest from CR72.
But if 'NS CPMG 2-site expanded' has been analysed (which nested from
CR72), should 'NS CPMG 2-site 3D' then
nest from CR72 or "the more precise" 'NS CPMG 2-site expanded' ?

It quickly arises to a two step problem.

In which order should the models be analysed?
> From which model should model nest from.

Best
Troels



2014-08-18 16:21 GMT+02:00 Edward d'Auvergne <edward@xxxxxxxxxxxxx>:
> Hi,
>
>
> > You will soon see my commits about sorting the models.
>
> I'm still catching up on your huge number of changes :)
>
>
> > And here we would probably have to discuss a little.
>
> It's best to discuss ideas before implementing them, as it's then far
> easier to change to the best course.  It's far more difficult once
> code and time has been invested into one solution when a better
> solution could have been first implemented.
>
>
> > There is a huge time potential to nest parameters from earlier models.
>
> This was a major point in our paper
> (http://dx.doi.org/10.1093/bioinformatics/btu166, and mentioned in the
> abstract) which I can now see has volume and page numbers :)
>
>
> > And so by common sense, it would/could be best to nest from numerical
> > solutions, since they are more precise.
> > But they are terrible slow.
>
> This is not a good idea :S  Well, the analytic models are
> approximations anyway so there is a bias in the parameter values, and
> this destroys any value the higher precision of the numeric models
> could give.
>
>
> > Unless they are these special hybrid version.
>
> Hybrid, I don't understand?
>
>
> > The word "silico", I took from:
> > A.J. Baldwin (2014). An exact solution for R2,eff in CPMG experiments
> > in the case of two site chemical exchange. J. Magn. Reson., 2014.
> > (10.1016/j.jmr.2014.02.023).
> >
> > I think it is a very good representation.
> >
> > "Silico" is "fast", and precise.
>
> Hmmm, maybe Nikolai should be asked about this.  I believe he would
> have a strong opinion about this categorisation of his model, and I
> don't remember him ever using such terminology.  Andy used the text
> "derived in silico" in the introduction which is quite different, as
> 'in silico' just means on a computer.  Most modern analytic models
> would also be derived using Mathametica, Maxima, etc. on a computer
> and could equally be said to be 'in silico' derived.  I bet Andy also
> used symbolic computational software for his paper ;)
>
>
> > But "impossible" to read and understand from the code.
> >
> > I think that "silico" is a good way to represent a "subset" of
> > numerical solutions.
> >
> > I would rather describe a model as being "silico", than to add meta
> > data about "how fast" it is.
>
> Why is this differential catagorisation needed at all?  I know this
> would invalidate a lot of work, but would it not be better to have
> hard coded nested model defaults?  I.e. a dictionary structure as you
> have already used in the variables module, with one entry per model.
>
> Regards,
>
> Edward