Page 1 of 1

bug found

Posted: Mon Jul 05, 2010 6:17 am
by Gannier
Hi,
I'm using Neuron version 7.2 (436::cbc0331180f8) 2010-04-05 and I found an annoying bug.
Plaese try this code

Code: Select all

strdef stemp
g = 2.2e-9
gk = 2.2e-9 * 1e11
sprint(stemp,"K%d",gk)
stemp
Normally, the display should be K220 but in fact, I obtain K219
Is this normal?

Best regards

No bug. Just another example of finite precision.

Posted: Mon Jul 05, 2010 1:42 pm
by ted

Code: Select all

oc>gk=2.2e-9*1e11
first instance of gk
oc>gk
        220 
oc>print gk
        220 
oc>int(gk)
        220 
oc>strdef foo
oc>sprint(foo,"%d",gk)
        1 
oc>foo
219
oc>{printf("%20.15f\n", gk)}
 219.999999999999972
oc>float_epsilon
        1e-11 
oc>float_epsilon=1e-20
oc>print gk
220 
oc>int(gk)
        219 
No bug. Just another example of the finite precision of digital calculations. 2.2e-9 is one of the many (most, in fact) numbers whose binary representation in most floating point libraries is an infinite series. It is truncated before being multiplied by 1e11. The result stored in gk is therefore not quite equal to 220. The small difference is obscured by hoc's
print gk
which reports the "single precision" evaluation of gk (i.e. truncated with rounding at 8 significant figures), and by
int(gk)
which truncates at a level of precision controlled by the built-in constant float_epsilon.

Please read the Programmer's Reference entry on float_epsilon, which governs logical comparisons and integer truncations of floating point numbers. With the default value of float_epsilon (1e-11), int(gk) is 220, but when float_epsilon is reduced to 1e-20, int(gk) returns 219.

Note that the documentation of float_epsilon contains the caveat that not every floating comparison in NEURON uses float_epsilon, but most of them do, including all interpreter logical operations, int, array indices, and Vector logic methods. Apparently sprint() and printf() also ignore float_epsilon--which is appropriate since printf statements are often an essential tool in ferreting out the causes of simulation errors.

The bottom line: avoid writing code that invites truncation error, e.g. by multiplying a very small number by a very large number and then expecting the result to be a whole number.

Re: bug found

Posted: Wed Jul 07, 2010 10:51 am
by Gannier
Thanks for your explanation Ted, I will take care of that.
so I changed for : sprint(stemp,"K%.0f",gk)
avoid writing code that invites truncation error, e.g. by multiplying a very small number by a very large number and then expecting the result to be a whole number.
OK but I need to do that. g is a conductance in a given unit and gk is used to create string and filename (in a court form).

Re: bug found

Posted: Wed Jul 07, 2010 3:31 pm
by ted
Gannier wrote:I need to do that. g is a conductance in a given unit and gk is used to create string and filename
I'd suggest a different strategy for naming files and managing data.
(in a court form).
A court form? What does the law have to do with this?

Re: bug found

Posted: Thu Jul 08, 2010 5:43 am
by Gannier
A court form? What does the law have to do with this?
sorry, I would say "short form" ("court" = short in french)

Re: bug found

Posted: Thu Jul 08, 2010 10:53 am
by ted
Gannier wrote:"short form" ("court" = short in french)
Ah, yes, as in Latin "curtus," similar to German "kurtz" although it seems strange that they would have borrowed that from Latin--maybe something more ancient gave rise to both? Sanskrit "hrasva" suggests a root like [h|k]rs.

Re: bug found

Posted: Thu Jul 08, 2010 11:43 am
by Gannier
ted wrote:Ah, yes, as in Latin "curtus," similar to German "kurtz" although it seems strange that they would have borrowed that from Latin--maybe something more ancient gave rise to both? Sanskrit "hrasva" suggests a root like [h|k]rs.
Yes, and if you compare Norvegian/Swedish/danish term (kort) it seem that all ("kurtz", "court", "short" and "kort") derive from a unique root.