Possible precision problem

Anything that doesn't fit elsewhere.
Post Reply
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Possible precision problem

Post by stephanmg »

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.
Thanks in advance.

Best,
Stephan
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Possible precision problem

Post by ted »

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?
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Re: Possible precision problem

Post by stephanmg »

Yes, i'm sorry for the imperfect description. But you got it nevertheless. Thank you so much.

HTH.

Best
Stephan
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Possible precision problem

Post by ted »

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;
Your choices are:
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().
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Re: Possible precision problem

Post by stephanmg »

Dear Ted,

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

Thanks in advance,
Stephan
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Re: Possible precision problem

Post by stephanmg »

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
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Possible precision problem

Post by ted »

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.
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Re: Possible precision problem

Post by stephanmg »

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?

Thanks for your quick reply,
best Stephan
stephanmg
Posts: 68
Joined: Tue Jul 03, 2012 4:40 am

Re: Possible precision problem

Post by stephanmg »

Thanks,

i found a bug in our code! :)

Best regards,
Stephan
Post Reply