Page 1 of 1

### Possible precision problem

Posted: Fri Aug 08, 2014 11:31 am
Dear NEURON users,

we're facing a strange problem:

The precision of a variable we retrieve from a .hoc file is different from a .modl file, i. e.:
let's consider variable foo with value 0.123456789,
retrieving it from hoc we receive the full length, i. e. 0.123456789, whereas when the variable foo is defined in a .modl file, we receive something like 0.123456.

Could it be related to this issue, maybe? => http://www.neuron.yale.edu/phpbb/viewto ... f=8&t=2022
This at least seems reasonble to me, since after IEEE 754 we arrive for single precision aka float at 7-8 reliable decimal digits.

Maybe someone could elaborate on that issue.

Best,
Stephan

### Re: Possible precision problem

Posted: Fri Aug 08, 2014 2:58 pm
stephanmg wrote:The precision of a variable we retrieve from a .hoc file is different from a .modl file, i. e.:
let's consider variable foo with value 0.123456789,
retrieving it from hoc we receive the full length, i. e. 0.123456789, whereas when the variable foo is defined in a .modl file, we receive something like 0.123456.
What does it mean to "retrieve a variable from a .hoc file" and what does it mean to "retrieve a variable from a .mod file"? Does that mean you have NMODL code for some mechanism foo that has a PARAMETER called "a" that is assigned a particular value
a = 0.123456789
and you found that this hoc code
a = 0.123456789
print a - foo.a
prints a nonzero value?

### Re: Possible precision problem

Posted: Fri Aug 08, 2014 3:19 pm
Yes, i'm sorry for the imperfect description. But you got it nevertheless. Thank you so much.

HTH.

Best
Stephan

### Re: Possible precision problem

Posted: Fri Aug 08, 2014 4:03 pm
Could it be related to this issue, maybe? => http . . .
No. The issue arises in the program that translates NMODL to c. The specific example that you provide generates a statement like this:
double a = 0.123457;
1. Accept the brutal, crude imprecison of life. Forget about parameters having more 5-6 decimal place precision. No biological parameter is known to that degree of precision, and no known critical biological function appears to require that degree of precision.
2. Refuse to accept biological reality. If some parameter really must be specified to > 5-6 place precision, do that assignment in hoc or Python. Or you could insert a statement like
a = 0.123456789
in the NMODL code's INITIAL block. This "hard wires" the exact value into the mechanism (generally not a good programming practice). Also the parameter does not get the exact value until after finitialize() has been called; indeed, unless you also assign it a value in the PARAMETER block it will be 0 until you call finitialize().

### Re: Possible precision problem

Posted: Mon Aug 11, 2014 2:59 am
Dear Ted,

that is great, thanks, and it explains the issue.

Stephan

### Re: Possible precision problem

Posted: Thu Aug 14, 2014 12:39 pm
ted wrote:
Could it be related to this issue, maybe? => http . . .
2. Refuse to accept biological reality. If some parameter really must be specified to > 5-6 place precision, do that assignment in hoc or Python. Or you could insert a statement like
a = 0.123456789
in the NMODL code's INITIAL block. This "hard wires" the exact value into the mechanism (generally not a good programming practice). Also the parameter does not get the exact value until after finitialize() has been called; indeed, unless you also assign it a value in the PARAMETER block it will be 0 until you call finitialize().
Dear Ted,

so writing the value in a INITIAL block auf our K4.mod file (let's call that variable foo for now), works to get the correct values in hoc! Thanks!

However,
we need to set the variable foo of the membrane mechanism K4 (in the mod file) to a new value, we do this by K4_za = 0.12345789!

However,
if we now access the variable again in hoc, we receive again 0.123456 not the value 0.123456789.

Can you please elaborate on this?
This would be so great, because we need that functionality for our NEURON-based projects.

Best,
Stephan

### Re: Possible precision problem

Posted: Thu Aug 14, 2014 9:04 pm
Variables have double precision but are printed only to 8 place accuracy unless you specify floating point precision with a format string.

Example--consider this density mechanism:

Code: Select all

``````: dummy.mod
NEURON {
SUFFIX bla
RANGE b
}
PARAMETER {
a = 0.123456789
}``````
Launch NEURON and manually enter a series of statements to see what NEURON actually does.

Code: Select all

``````oc>create soma
oc>access soma
oc>insert bla
oc>a_bla
0.123457``````
because translation from NMODL to C limits parameter precision. Check by using a printf statement with a format string:

Code: Select all

``````oc>printf("%12.9f\n", a_bla)
0.123457000``````
Try to force higher precision.

Code: Select all

``````oc>a_bla = 0.123456789
oc>a_bla
0.12345679``````
That looks better, but if we use printf with a suitable format specification

Code: Select all

``````oc>printf("%12.9f\n", a_bla)
0.123456789``````
we can verify total success.

### Re: Possible precision problem

Posted: Fri Aug 15, 2014 2:48 am
Dear Ted,

that's interesting.
I'm using in my C code the expression hoc_valid_stmt("a_bla = 0.123456789", 0);

Then, if i retrieve it with:
double hoc_ac_;
hoc_valid_stmt("hoc_ac_ = a_bla");

I receive again lower precision, i. e. 0.123456 for example.

Is this to be expected?