Using a variable to set vector size - problem

[Qroid_montreal]

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>

[ted]

At the oc> prompt, type this
NtimeSteps-359
then press the "Enter" key.
What do you see?

[Qroid_montreal]

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?

[ted]

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?

[ted]

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?