The commit message does not match the change in any way!
Regards,
Edward
On 20 June 2014 08:29, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Fri Jun 20 08:29:42 2014
New Revision: 24183
URL: http://svn.gna.org/viewcvs/relax?rev=24183view=rev
Log:
Moved the costly
If I can work out how to eliminate all looping in the numeric models,
you might have to revert this ;)
Regards,
Edward
On 20 June 2014 08:37, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Fri Jun 20 08:37:29 2014
New Revision: 24186
URL:
The checking code should have been in a different commit - or even
better a different commit adding this as a unit test. Also, shift the
fixed matrices out of the function for speed.
Cheers,
Edward
On 20 June 2014 09:18, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Fri Jun 20
Great work! You can take this much, much further though and move the
M1_M2, M2_M1, M1_M2_star, M2_M1_star, M1_M2_M2_M1_star, and
M2_M1_M1_M2_star dot products out of the loop. For this model, that
would be a huge win! Then for this model, just like the other numeric
models, the only thing
Hi Troels,
There is a faster way to do this - eliminating the 'if' statements. I
don't know how much faster though, as it is clearly currently not a
bottleneck, but it might cause the code to be much faster later when
other changes to the numeric models occur. What would be better is to
Hi Troels,
I think that this is reasonable. Numpy 1.6.0 was released on
2011-05-15, so this is now 3 years old. For speed in the numeric
dispersion models, this now appears to be quite important. I think
that we only need to change the documentation and webpage
These could also be called
matrix_exponential_rank_NE_NS_NM_NO_ND_x_x(), or what ever you wish.
Regards,
Edward
On 23 June 2014 11:09, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
There is a faster way to do this - eliminating the 'if' statements. I
don't know how much faster
Hi Troels,
Please try to keep code changes separate. You have two changes in
this commit. One is documented by the commit message, but the other
change is hidden and only visible when looking at the lines changed.
That is a bit too messy.
Cheers,
Edward
On 20 June 2014 12:00,
Hi,
These really should all be numpy.complex128 - the double precision
complex floats. Setting this to numpy.complex64 drops the accuracy to
single precision which may introduce truncation artefacts. Note
though that if all data structures in a dispersion model can be
converted from double to
Have you thought of adding profiling scripts for the 3-site dispersion
models as well? This could just be the same as the 2-site models and
where states B and C are identical. It should be easy and quick to
duplicate one of the 2-site model scripts, duplicate all structures
for both B and C
As before, all the dot products of M1, M2, M1* and M2* can also be
shifted out of the loops for large speed increases.
Regards,
Edward
On 20 June 2014 17:42, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Fri Jun 20 17:42:56 2014
New Revision: 24212
URL:
As before, you could convert this into a unit test. The easiest way
would be to jump back to this revision and use print statements to
obtain all the values required to set up and execute a unit test.
Regards,
Edward
On 20 June 2014 19:13, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date:
Hi,
1) Move matrix_exponential_rankN, to lib.dispersion.matrix_exponential.
OK. Done.
This is good, as the function is dispersion specific and is not general.
1a) Split into matrix_exponential_rank6, and matrix_exponential_rank7. Add
unit tests.
OK. Done.
This should be better for
Hi Troels,
In general you need to be careful when deleting an author from the
copyright notice. Even if there are no lines in common with the
original file, the copyright should not be removed out of respect for
the author. In this case it is ok, as you are spinning just your code
out of
For the comment Repetitive calculations (to speed up calculations).,
I would recommend changing this to something like Once-off generation
of the constant matrices used for constructing the exchange matrix..
These are now only generated once, so they are no longer repetitive.
Cheers,
Edward
On
more time for anything
strictly needed.
Best
Troels
On 17 Jun 2014 22:55, Edward d'Auvergne edw...@nmr-relax.com wrote:
Not quite yet ;) I have to merge this back to trunk. But first I need to
see if there is anything to clean up (whitespace, comments, formatting,
naming consistency, API
with ##
which would be better as #. I'll keep looking.
Cheers,
Edward
On 17 June 2014 22:55, Edward d'Auvergne edw...@nmr-relax.com wrote:
Not quite yet ;) I have to merge this back to trunk. But first I need to
see if there is anything to clean up (whitespace, comments, formatting,
naming
, I'll
keep looking at the code and expand the list as needed.
Cheers!
Edward
On 18 June 2014 08:30, Edward d'Auvergne edw...@nmr-relax.com wrote:
Oh, and the DPL94 profiling script is not in a functional state. So
only analytic CPMG models are covered. One R1rho model would be
useful
Are the graphs now correct (https://gna.org/bugs/?22212)? These
commits should avoid a lot of changes in the rest of
specific_analyses.relax_disp to handle the back_calc numpy array
structure.
Cheers,
Edward
On 18 June 2014 09:25, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun
.
This bug will though occur, if there is missing data for spin.
Best
Troels
2014-06-18 9:32 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Are the graphs now correct (https://gna.org/bugs/?22212)? These
commits should avoid a lot of changes in the rest of
specific_analyses.relax_disp
there is still some bugs out there.
For example, I don't handle missing R1.
In the lib functions, there are set to 0.0, and target function expects to
be able to expand this to higher dimensionality.
I have to check it.
Best
Troels
2014-06-18 9:45 GMT+02:00 Edward d'Auvergne edw...@nmr
in the
branch. They do not occur in the trunk.
Regards,
Edward
On 18 June 2014 09:28, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
I have some more points added to the running list. Most of these are
very basic clean ups:
- Shift once off parameter conversions to lib.dispersion
=model.back_calc,
completed=False))
2014-06-17 23:23 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
It's not really necessary to create a bug report for the development
branches, as the bug tracker is more for communicating with users and
the users will not use the branch code. We can
(processor=processor,
memo_id=self.memo_id, param_vector=param_vector, chi2=chi2,
iter_count=iter_count, f_count=f_count, g_count=g_count, h_count=h_count,
warning=warning, missing=self.missing, back_calc=model.back_calc,
completed=False))
2014-06-17 23:23 GMT+02:00 Edward d'Auvergne edw
No problems. This is needed for the release notes. I was just hoping
that you'd get the DPL94 model running so we can have one number over
100 times faster ;) The more models we have profiling numbers for,
the more awesome the speed ups look!
Regards,
Edward
On 18 June 2014 11:39, Troels
, if just some of the spins
have
dw = 0.0.
Best
Troels
2014-06-18 9:04 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
I'll make a running list of things to be done prior to merger of the
branch. These include my previous points, and a few new ones:
- Shift once off parameter
Hi,
If you would like to tackle this one, that would be legendary. Though
you must decide if it is worth your time. There are also still a few
things to tidy up for the disp_spin_speed branch to prepare it for
merger. For your idea, I would suggest considering the following:
1) Creating a
Hi,
You are aware of the lib.linear_algebra.matrix_exponential and
lib.linear_algebra.matrix_power modules right?
Regards,
Edward
On 18 June 2014 13:33, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
If you would like to tackle this one, that would be legendary. Though
you must decide
Edward d'Auvergne edw...@nmr-relax.com:
Hi,
You are aware of the lib.linear_algebra.matrix_exponential and
lib.linear_algebra.matrix_power modules right?
Regards,
Edward
On 18 June 2014 13:33, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
If you would like to tackle this one
Awesome! I'm regenerating all the statistics for the branch vs.
relax-3.2.2 now, using this DPL94 model as well. It takes a while
though!
Regards,
Edward
On 18 June 2014 15:44, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun 18 15:44:58 2014
New Revision: 24091
URL:
models now
:)
Regards,
Edward
On 18 June 2014 15:58, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
:-)
2014-06-18 15:55 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Awesome! I'm regenerating all the statistics for the branch vs.
relax-3.2.2 now, using this DPL94 model as well
This script is unfortunately now failing.
Regards,
Edward
On 18 June 2014 16:03, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun 18 16:03:46 2014
New Revision: 24093
URL: http://svn.gna.org/viewcvs/relax?rev=24093view=rev
Log:
Changes to profiling script of
This is also now failing.
Regards,
Edward
On 18 June 2014 16:07, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun 18 16:07:10 2014
New Revision: 24094
URL: http://svn.gna.org/viewcvs/relax?rev=24094view=rev
Log:
Made changes to the profiling script of NS_CPMG_2SITE_3D.
Need
, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Any other god model to show for?
2014-06-18 16:22 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Feel free to use the super script to run all of your scripts and to
get the final summary. You could make a nice compact table from
dimensionality, and BANG BANG
matrix style. :-)
We have one core group who does a lot of simulation, so maybe they would
grasp it.
Best
Troels
2014-06-18 16:05 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
While I am regenerating this, I would highly recommend you copy this
script
The only issue is me keeping up with you ;)
On 18 June 2014 16:56, Edward d'Auvergne edw...@nmr-relax.com wrote:
They are all good! I'd say that they are all awesome :) Even the
numeric models are almost twice as fast. The more you can quickly
add, the better - you pretty much now have
Hi Troels,
I'm guessing that you already know this, but this is still executing
the DPL94 model rather than NS R1rho 2-site model.
Regards,
Edward
On 18 June 2014 16:48, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun 18 16:48:50 2014
New Revision: 24100
URL:
:
How?
MODEL_NS_R1RHO_2SITE
self.model.func_ns_r1rho_2site(params)
Best
Troels
2014-06-18 17:04 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
I'm guessing that you already know this, but this is still executing
the DPL94 model rather than NS R1rho 2-site model.
Regards
!
Regards,
Edward
On 18 June 2014 17:14, Edward d'Auvergne edw...@nmr-relax.com wrote:
Very good question. It must be a version mix up. My current
profiling looks like:
Execution iteration 1
$ python profiling_cr72.py
10.0700.0001.7500.000
relax_disp.py:938
Hi Troels,
You have a chi-squared printout in all of your profiling scripts, but
do you know why that value is so high in all scripts?
Regards,
Edward
On 18 June 2014 17:27, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Wed Jun 18 17:27:54 2014
New Revision: 24110
URL:
between values and back_calc.
If I remember, all values are set to 2.0, errors 1.0.
Best
Troels
2014-06-18 17:29 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
You have a chi-squared printout in all of your profiling scripts, but
do you know why that value is so high in all
Hi Troels,
In another ~30 min, I'll update this file again with the 'M61',
'TP02', 'TAP03', and 'MP05' model results as well. If you could find
the time, would you be able to create profiling scripts for the the
'LM63', 'IT99', and 'NS CPMG 2-site star' models as well (again these
should only
hard work.
Regards,
Edward
On 18 June 2014 18:13, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
In another ~30 min, I'll update this file again with the 'M61',
'TP02', 'TAP03', and 'MP05' model results as well. If you could find
the time, would you be able to create profiling
The speed ups will be greater for the models with only R20 rather than
R20A and R20B, but I don't know by how much. It might make the
analytic model speed ups look more impressive.
Regards,
Edward
On 18 June 2014 18:29, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
You could even
This is a summary of the speed ups for the current version of the
branch (r24110). The models that have no profiling information have
been added with values of '?' to allow a summary table of all
supported relaxation dispersion models to be created. I think that
such a table will be used in the
2014-06-16 19:21 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
There is something that worries me in this change, specifically:
-num_points_si_mi = int(num_points[0][si][mi][0][0])
+num_points_si_mi = int(num_points[0][si][mi][0
Hi Troels,
Now that your array structures are well defined and all within one
clear block in the target function __init__() method, I thought that
maybe it would be a good time to reconsider the data assembly
functions and design in the specific_analyses.relax_disp package.
What I mean is that
Hi Troels,
For this change, you have introduced the chi2_rankN() function, but it
is still calculated per experiment. As this model is almost always
used with up to 6 different experiments, this will still be slower
than what is possible. You should change this to match the other
target
Hi Troels,
Now that you have converted almost all data structures to numpy
arrays, you should change how these are accessed. For example a[1, 1]
is cleaner than a[1][1] and is the standard way to index a numpy
array. It is also faster:
$ python -m timeit -n 1000 -s import numpy a =
for looping over power, to evolve the matrix.
They should have been removed from all analytical models.
Best
Troels
2014-06-17 9:26 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
What were the original indices in num_points[0][si][mi][0][0]? Were
they [ei][si][mi][oi][di]? I guess
on with my data analysis.
Best
Troels
2014-06-17 9:50 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Now that your array structures are well defined and all within one
clear block in the target function __init__() method, I thought that
maybe it would be a good time
Hi,
I think this is one of those cases where we will see that a future
numpy version will implement this correctly and fast. I've been
looking into the numpy 1.8.1 source code, and the inplace operation
and the speed of the out argument appear to be unrelated. Anyway,
numpy 2 might implement
this efficient.
I wasted 6 hours for a first try to convert it, so this has to be step by
step.
You have still won the looping over spins and frequency.
So it should be faster.
Best
Troels
2014-06-17 10:04 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
For this change, you have
This is very strange. It only affects that single spin.r2[r20_key3]
parameter and the chi-squared value. H, what is happening?
Regards,
Edward
On 16 June 2014 23:29, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
This is weird.
It has found a lower chi2 value?
# Checks
Ah, that is probably because of a bug you fixed
(https://gna.org/bugs/?21954). The results were generated before this
bug was fixed, so now they will be slightly different as the
test_suite/shared_data/dispersion/Hansen/base_pipe.bz2 and
test_suite/shared_data/dispersion/Hansen/r2eff_pipe.bz2
Hi,
Rather than minimisation, just call the calc user function as this is
the proper way to get the chi-squared value at the current parameter
values. One iteration of simplex minimisation can actually shift the
parameter values. And if the test is fast, just leave it there. It
doesn't need to
analysis?
2014-06-17 11:08 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Ah, that is probably because of a bug you fixed
(https://gna.org/bugs/?21954). The results were generated before this
bug was fixed, so now they will be slightly different as the
test_suite/shared_data/dispersion
.
Right now I am looking at the missing flag.
2014-06-17 10:49 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
This is very strange. It only affects that single spin.r2[r20_key3]
parameter and the chi-squared value. H, what is happening?
Regards,
Edward
On 16 June 2014 23:29
Maybe the masking logic does not work within the experiment index
loop. But I don't know the exact reason why this fixes the bug.
Regards,
Edward
On 17 June 2014 11:36, Edward d'Auvergne edw...@nmr-relax.com wrote:
Actually, if you deindent the lines after the self.r2eff_ns_mmq[ei
Hi,
This is in progress. I need to work out if there is a problem with
the data generation script
(test_suite/shared_data/dispersion/lm63_3site/generate.py), the R2eff
calculating script
(test_suite/shared_data/dispersion/lm63_3site/r2eff_calc.py), the
system test itself, or a bug in the
Hi,
There's no need to delete this - it's a useful test as it is on real
data. Once the Relax_disp.test_lm63_3site_synthetic system test is
debugged and working, this
Relax_disp.test_hansen_cpmg_data_to_lm63_3site test can be updated.
There is no such thing as too much testing :)
Regards,
Hi Troels,
You can take this one step future. Replace all the following:
- [ei, si, mi][:] with [ei, si, mi, :],
- [0][si, mi] with [0, si, mi],
- [ei, si, mi, oi][:num_disp_points] with [ei, si, mi, oi, :num_disp_points],
- [0, si, mi, 0][di] with [0, si, mi, 0, di]
The important point is
Oh, I was a bit too fast
(http://thread.gmane.org/gmane.science.nmr.relax.scm/21776/focus=6301).
Anyway, there are still a few more:
[edward@localhost disp_spin_speed]$ grep ]\[ lib/dispersion/*
Regards,
Edward
On 17 June 2014 13:07, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Tue
:27, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi,
There's no need to delete this - it's a useful test as it is on real
data. Once the Relax_disp.test_lm63_3site_synthetic system test is
debugged and working, this
Relax_disp.test_hansen_cpmg_data_to_lm63_3site test can be updated
Hi Troels,
This is a very important change for the dispersion analysis (and to
the frame order analysis as well). I have found that the log barrier
constraint algorithm was not tuned optimally in the minfx library
(https://gna.org/projects/minfx/), and have fixed it upstream
.
Regards,
Edward
On 17 June 2014 14:55, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Is that version 1.0.6 ?
Or is it newer?
2014-06-17 14:48 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
This is a very important change for the dispersion analysis (and to
the frame
Hmmm, I'm wondering if the numpy notation might be more correct here
[NE][NS][NM][NO][ND] - [NE, NS, NM, NO, ND]:
$ sed -i 's/\[NE]\[NS]\[NM]\[NO]\[ND]/\[NE, NS, NM, NO, ND]/g'
lib/dispersion/*.py
It's also easier to read.
Regards,
Edward
On 17 June 2014 14:53, tlin...@nmr-relax.com wrote:
Hi Troels,
For the variables you have added as aliases to the larger structure,
it might be simpler for a relax user to read the code if the
_si_mi_oi part is removed. For example r20a_si_mi_oi to r20a,
dwH_AC_si_mi_oi to dwH_AC, etc. There's no loss of generality
there, and it's very easy to
at the optimisation for the
second spin. It looks like the tuned log barrier algorithm can handle
these tough edge cases much better now.
Regards,
Edward
On 17 June 2014 15:00, Edward d'Auvergne edw...@nmr-relax.com wrote:
It'll soon be version 1.0.7. You'll probably be interested to note
Oh, sorry, I was back to front :S More edge cases with pA = 0.5
actually appear due to the better optimisation.
Regards,
Edward
On 17 June 2014 15:31, Edward d'Auvergne edw...@nmr-relax.com wrote:
You might also be interested to know that it affects some of the
problems where pA is stuck
Sorry, I meant the Relax_disp.test_hansen_cpmg_data_to_lm63_3site
system test that was deleted in r24024 in trunk.
Cheers,
Edward
On 17 June 2014 17:13, Edward d'Auvergne edw...@nmr-relax.com wrote:
Hi Troels,
Note that after this commit, you must absolutely use the new minfx
1.0.7 that I
Hi Troels,
Note that after this commit, you must absolutely use the new minfx
1.0.7 that I just released
(https://gna.org/forum/forum.php?forum_id=2466). All relaxation
dispersion system tests now pass in trunk, including the new
Relax_disp.test_lm63_3site_synthetic test. You should restore the
Molecular dynamics by NMR data analysis
Copyright (C) 2001-2006 Edward d'Auvergne
Copyright (C) 2006-2014 the relax development
team
This is free software which you are welcome to modify and redistribute
under the conditions
That commit message might be a bit misleading when I present it to all
relax users. It sounds like the 'NS R1rho 3-site' model is new. You
have to be a bit more careful what you write, as I present your text
in all of the relax announcements.
Regards,
Edward
On 17 June 2014 19:27,
of power, but happy with the result!
Best
Troels
2014-06-17 19:35 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
That commit message might be a bit misleading when I present it to all
relax users. It sounds like the 'NS R1rho 3-site' model is new. You
have to be a bit more careful
Not quite yet ;) I have to merge this back to trunk. But first I need to
see if there is anything to clean up (whitespace, comments, formatting,
naming consistency, API consistency, etc.). And then this needs to be
released to all relax users, either as relax 3.2.3, or as 3.2.4 with 3.2.3
being
Of course, that a good idea. The task is to complain harder with a
RelaxError when R1 data is not loaded and one of the off-resonance
R1rho models are selected (but not for M61 and other on-resonance
models, as we need to support these and the special R1rho-R1
experiment type). But we should get
I saw this as you were changing the wiki :) And I clearly remember
the pain you had in getting the GUI running on your EPD Python. This
wiki is really awesome for collecting such information. Btw, have you
seen the insane number of spam bots on the wiki
Hi,
It's not really necessary to create a bug report for the development
branches, as the bug tracker is more for communicating with users and
the users will not use the branch code. We can just discuss on the
list. For this, I would strongly suggest you consider adding
get_back_calc() method
Hi,
Using manual bisection, I found the problem originates with r23946
(http://thread.gmane.org/gmane.science.nmr.relax.scm/21696,
http://svn.gna.org/viewcvs/relax/branches/disp_spin_speed/target_functions/relax_disp.py?view=diffr1=23945r2=23946pathrev=23946).
The problem is clearly as follows.
Hi Troels,
Be careful here, you have committed a print statement that is fatal
for Python 3.
Regards,
Edward
On 16 June 2014 19:01, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Mon Jun 16 19:01:39 2014
New Revision: 23990
URL: http://svn.gna.org/viewcvs/relax?rev=23990view=rev
Hi Troels,
There is something that worries me in this change, specifically:
-num_points_si_mi = int(num_points[0][si][mi][0][0])
+num_points_si_mi = int(num_points[0][si][mi][0])
This is in the numeric models for CPMG-type data. Have you dropped
the offset dimension?
Hi Troels,
Is this actually faster? I just wrote a script to test this at
https://gna.org/task/index.php?7807#comment199. The log file with the
results is also attached. This is also archived at
http://article.gmane.org/gmane.science.nmr.relax.devel/6240. If you
look at that, I think I can
That's a great idea! That'll save so much time!
Edward
On 15 June 2014 08:53, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Sun Jun 15 08:53:40 2014
New Revision: 23953
URL: http://svn.gna.org/viewcvs/relax?rev=23953view=rev
Log:
Wrote the essential dot matrix up to be initiated
Hi,
If this works, that'd be a great speed up! For the t_mat matrix,
maybe you could name it as the evolution_matrix. That would make it
clear as to what it really is. Remember that long and descriptive
variable/class/function/method names are a feature of the relax source
code - with the aim
Hi Troels,
Can this reshape happen in the target function __init__() method
instead, directly where M0 is initialised, i.e. self.M0 = zeros((7,
1), float64)? That would be faster by avoiding this operation in the
target function calls, though considering how slow the rest of the
numeric model
Hi,
Does the test script work
(https://gna.org/support/download.php?file_id=21021)? You should see
the same matrix printed 3 times.
Regards,
Edward
On 15 June 2014 14:57, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Hi Edward.
I have tried the out argument, but it wont work ???
.
http://wiki.scipy.org/PerformanceTips
2014-06-15 10:33 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
Is this actually faster? I just wrote a script to test this at
https://gna.org/task/index.php?7807#comment199. The log file with the
results is also attached
Hi Troels,
This is just a small formatting fix - the '=' need spaces ' = ' when
not a function argument. And the reverse for a function argument,
with 'dw == 0.0' as 'dw==0.0'. Just a standard Python, and relax,
convention.
Cheers,
Edward
On 15 June 2014 15:15, tlin...@nmr-relax.com
One more thing, for the link:
http://www.huyng.com/posts/faster-numpy-dot-product/
Note that this guy has not gone to the numpy mailing list. Often
there is a hidden reason for this, and one must be always wary. It is
likely that he hasn't used any ideas from
Hi Troels,
In this change, only in one line have you used the numpy.dot() out argument:
+dot(Rexpo, r180x, evolution_matrix)
So it must be working. You can do this for all others, replacing:
-evolution_matrix = dot(evolution_matrix, Rexpo)
+
Hi Troels,
You had it working in the first way that has been deleted in this commit:
-dot(Rexpo, r180x, evolution_matrix)
I would really prefer to avoid making SciPy a dependency for relax
users performing a dispersion analysis. It is only needed for the
frame order analysis,
to get this working for you!
Regards,
Edward
On 15 June 2014 16:21, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Hi Ed.
I can see that you are pushing for this.
It wont work!
2014-06-15 16:12 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi Troels,
In this change, only
somewhere.
2014-06-15 16:25 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Which numpy version are you using? There is a damn good reason why I
am pushing this. I know that all of the competition software (at
least cpmg_fit and CATIA) uses exactly this storage concept, though in
C
here
http://thread.gmane.org/gmane.comp.python.numeric.general/28135/
Somewhere I saw, that there is maybe a bug here.
2014-06-15 16:53 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Hi,
It does look like there is a bug somewhere in one version of
numpy.dot(). I'll look
Hi Troels,
Thanks to the lightning quick infrastructure you are putting into
place, we can also simplify the target_functions.relax_disp to
lib.dispersion API. You will notice a lot of code like in this TP02
model:
+# Once off parameter conversions.
+pB = 1.0 - pA
This was
10:18, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Hi ed.
All the:
num_points=self.num_disp_points_a
can also be killed.
They are not used.
The disp_struct is actually this structure, in higher dimensions?
Best
Troels
2014-06-13 9:02 GMT+02:00 Edward d'Auvergne edw...@nmr
Now this code might be too fast for the user - they may not be fast
enough to even see it in the log files ;)
Regards,
Edward
On 13 June 2014 10:10, tlin...@nmr-relax.com wrote:
Author: tlinnet
Date: Fri Jun 13 10:10:04 2014
New Revision: 23908
URL:
, that if I wanted to have the systemtests go faster,
I should kill this one.
It is nice to see, that systemtest suite just runs faster and faster, the
more models
i kill.
2014-06-13 10:37 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
Now this code might be too fast for the user - they may
time down by a large
percentage.
Regards,
Edward
On 13 June 2014 11:07, Troels Emtekær Linnet tlin...@nmr-relax.com wrote:
Can one profile the systemtests ?
Best
Troels
2014-06-13 10:56 GMT+02:00 Edward d'Auvergne edw...@nmr-relax.com:
For me the system tests are not much faster compared
601 - 700 of 2509 matches
Mail list logo
