On 8/6/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
Edward d'Auvergne wrote:
On 7/26/07, gary thompson <garyt.and.sarahb@xxxxxxxxx> wrote:
On 7/23/07, Sebastien Morin < sebastien.morin.1@xxxxxxxxx> wrote:
[snip]
This is part of the changes from the 1.2 to the 1.3 line.
The default CSA value we're talking about here is only the system's CSA
that is used in the test-suite and also in the program when someone
doesn't
set a value. That said, the value used by someone can be input in the
scripts like it is the case in the sample scripts (e.g. value.set(name,
-172 * 1e-6, 'csa') ). So, a global default value as is planned in the
1.3
line should be used everywhere except in the sample scripts
most probably the default value should be used in the sample scripts as
well... it will get the users into the good habit of using named constants
I would prefer that we have raw numbers in the script. That will then
not discourage the user from changing the value if they wish. If
instead of
value.set(name, -172 * 1e-6, 'csa')
we have
value.set(name, N15_CSA, 'csa')
in the script then the user is less likely to change the value
(whether this is good or bad is debatable).
However, the second is better practice: bugs with typos etc are much
less likley to creap in, what the number is is also alot clearer to the user
how about 15N_CSA_160PPM etc
value.set(name, 15N_CSA_160PPM, 'csa')
If someone is working on 17O data, then for them logically they would
have something like:
value.set(name, 17O_CSA_xxxPPM, 'csa')
But these things cannot all be defined in advance. I would much
prefer a floating point number so they know they can use a floating
point number there (asking non-coders to know that 15N_CSA* are
floating point numbers is too much).
Don't forget that these are the sample user scripts which, from the UI
perspective, I would strongly prefer to avoid as many coding
conventions as possible. Although the scripts are Python code, I
would prefer for it to not look that way for as many of these scripts
as possible. Coding skills shouldn't be a requirement for using
relax.
The other point is that
with the obligatory statement
from physical_constants import N15_CSA
the modified scripts of the user will be less portable if we ever
change file names, constant locations, constant naming, etc.
this can be fixed using programmatic module imports which give
deprecation warings so again is not a problem and it is a small price to
pay for a clearer more maintainable code base. Magic numbers should
always be eliminated at all possible junctures ;-)
Again this is for developers rather than for relax users, most of
which will be non-coders. Most users will have no idea what to do
about depreciation warnings. And as the sample scripts are not part
of the relax source code, these aren't really 'magic numbers' hidden
within the code base but rather a user defined configuration.
Regards,
Edward
Re: CSA & bond length