Page 1 of 1

### Using a variable to set vector size - problem

Posted: Fri Apr 20, 2012 11:05 am
I'm encountering the following problem when using a variable to resize a vector. Briefly I use scanvar() to read in a value, then use this to calculate NtimeSteps. As you can see, NtimeSteps is initially 359, but tmpvec.resize(NtimeSteps) results in a vector with 358 elements. When I set NtimeSteps to 359 explicitly this problem goes away. What am I doing wrong? I'm guessing it's a rounding or precision error from the original calculation of NtimeSteps, but why can't I see it?

Code: Select all

``````oc>NtimeSteps
359
oc>objref tmpvec
oc>tmpvec=new Vector()
oc>tmpvec.resize(NtimeSteps)
Vector[1309]
oc>tmpvec.size
358
oc>NtimeSteps=359
oc>NtimeSteps
359
oc>tmpvec.resize(NtimeSteps)
Vector[1309]
oc>tmpvec.size
359
oc>
``````

### Re: Using a variable to set vector size - problem

Posted: Fri Apr 20, 2012 11:25 am
At the oc> prompt, type this
NtimeSteps-359
then press the "Enter" key.
What do you see?

### Re: Using a variable to set vector size - problem

Posted: Fri Apr 20, 2012 11:53 am
ted wrote:At the oc> prompt, type this
NtimeSteps-359
then press the "Enter" key.
What do you see?
-5.6843419e-14

Ah, I see. And Vector.resize(n) floors n, right? If so, is it generally a good technique to use n+0.5 when resizing?

### Re: Using a variable to set vector size - problem

Posted: Fri Apr 20, 2012 10:36 pm
Qroid_montreal wrote:Vector.resize(n) floors n, right?
Treats it the same way int() would.
If so, is it generally a good technique to use n+0.5 when resizing?
Not necessarily. Your problem most likely arose from something that hasn't yet been disclosed in this thread.
I use scanvar() to read in a value, then use this to calculate NtimeSteps.
Which begs two questions:
1. Exactly what "value" was read by File.scanvar(), by which I mean, exactly what was the string that File.scanvar() parsed?
2. Exactly what was the calculation that generated the value assigned to NtimeSteps?

### Re: Using a variable to set vector size - problem

Posted: Sat Apr 21, 2012 10:52 pm
Forget it--I see many potential problems in code you posted in a different thread. Statements like these
tstop=del + dt*NtimeStepsStim + TimeAfterStim // stop
NtimeSteps = (del + dt*NtimeStepsStim + TimeAfterStim)/dt
for ii=0,del/dt + NtimeStepsStim + TimeAfterStim/dt - 1
if (ii<=del/dt || ii>del/dt+NtimeStepsStim)
can produce results that may or may not be what you wanted, all because of roundoff error. It is particularly dangerous to treat the results of floating point calculations as if they were integers, as is done in the following expressions:
NtimeSteps = (del + dt*NtimeStepsStim + TimeAfterStim)/dt
for ii=0,del/dt + NtimeStepsStim + TimeAfterStim/dt - 1
if (ii<=del/dt || ii>del/dt+NtimeStepsStim)
(I omitted the "tstop=del + . . . " from this list only because I don't know if it's guaranteed to cause a problem, as the others are).

On a case-by-case basis, you need to think about each of these and decide, in advance, whether roundoff error will cause a problem. If you aren't sure, convert problematic expressions to forms that are guaranteed to produce integer results.

Which brings up this question again:
is it generally a good technique to use n+0.5 when resizing?
I wouldn't bother doing that if n is guaranteed to have an integer value. If it isn't, I'd pass int(n+0.5) as the argument to resize()--why leave anything to chance?