From: Eric E. <eri...@na...> - 2008-02-24 13:40:32
|
Hi Juraj, > Thanks Eric, > > I did find my error following your suggestion. In the end it came down to > an > UGLY error represented in the following symbolic code: > > double time = someNumberDependingOnPreviousCode; > > for(Size i=outsideArray.size()-1; i>=0;i--) > { > if( outsideSTLVector[i] > time ) > { > manipulate some numbers to be used outside this for loop; > } > else > break; > } > > > The problem is two-fold in the above code, which makes it work in debug > mode > but not in release. (Can you find it quick without reading below?:-)). > > > The first catch is that the loop variable is of type QuantLib:Size, which > is > just a typedef for an unsigned int. When it happens that "time = 0" and > outsideArray[i] >0 for all "i" in the relevant range, then the for loop > keeps running all the way down to i=0, then decrements "i" from this zero > value, which for an unsigned int happens to produce (on my computer) > 4294967295 and then it tests the loop condition that is now happily > satisfied due to the large value of "i". Thus it enters the loop again and > now tries to access "outsideSTLVector[4294967295]" in the if condition. > Now > comes the second catch. In the debug mode this evaluates to a garbage > value > of, roughly, "-7.845 e+298" so a negative number which makes the if > condition false (since time = 0) and the break then forces execution of > out > the loop without mangling up the numbers manipulated inside the if. In the > release mode, however, the garbage value happens to be roughly > outsideSTLVector[4294967295] = 2.189 e-303 (>0) so the if condition is > satisfied and hell breaks loose... > > Anyway, bottom line is, this was a trivial programming error which cost me > a > loooooot of time (it just happened that I stepped through the loop > hundreds > of times but the "right" circumstances for it to go wrong only happened > once > in the entire run of the program...). > > nice weekend to QuantLib users, > > Juraj I'm surprised that outsideSTLVector[4294967295] returns garbage - I would expect instead in both Debug and Release that statement would cause the app to crash on an attempt to access a subscript that is presumably out of range. No matter, I'm sure I'm missing something trivial, very glad to hear you worked it out! Happy rest of weekend to you too. Regards, Eric |