behavior of runge-kutta function rk in single step operation inside loop

On 10-07-2013 20:22, Edwin Woollett wrote:
> On July 9, 2013, Volker van Nek wrote:
> --------------------
>> With a by 1e-15 slightly extended range the steps are as expected.
>>
>> soln2 : rk (-'n, 'n, n, ['t, t, t+dt+1e-15, dt]);
>>
>> I draw the conclusion that rk cannot guarantee that the right end of 
>> the range is always reached. Don't know if this a >bug or a typical 
>> numerical problem.
> --------------------------------------
> Thanks for the work-around, which works for me and gives me
>  rk output that when plotted with points style is positioned
>  more clearly than if I used dt = 1/8 = 0.125.
>
> By the way, redefining dt with the extra increment 1e-15 at the
> start doesn't cure the problem: 
Of course not. The cause of the problem is that 0.1 is represented 
internally as n1/d1 and 0.3 as n3/d3 (n1, n3, d1 and d3 integers). You 
can check the following:
   10*n1 - d1 = 2
   10*n3 - 3*d3 = -2
which means that n1/d1 is actually bigger than 0.1 and n3/d3 is actually 
smaller than 0.3. When you sum the step 3 times you think your result is 
0.3 but it is actually 3*n1/d1, which is bigger than 0.3 and, therefore, 
also bigger than 0.3.
When the interval  ['t, 2*n1/d1, n1/d1, n3/d3] is given to rk, it 
currently returns a first point at t=2*n1/d1 but then it checks that 
3*n1/d1 is above the upper limit n3/d3 so it ignores that second point.

By adding 1e-15 you are making the problem worse since you are making dt 
even bigger than 0.1 instead of making it less than 0.1. Perhaps you 
could subtract 1e-15 instead of adding it.
In general you can use ['t, t, t+1.5*dt, dt] which indicates more 
clearly that you want the last value of 't close to t+dt but not 
becoming t+2*dt
(the 1e-15 trick implies that you know the number of digits used in the 
current floating-point representation).

Regards,
Jaime