Problem with calculation time of a nested function

[ptc-5419055]

I try to plot the current through a Resistor-Coil Network with the following function. The following variable are defined static outside the equation (I_Anker_max, f_T, t_ein) and don't matter to much anyway. The issue I am having is that with increasing range of nx the calculation time rises exponentially and I even think that I know why. In my opinion the reason is that every time the Loop starts it calculates the hole thing from scratch. Unfortunately I am quite new to Mathcad and don't have any idea how to solve that. I'd be glad if someone had an advise for me.

Best regards Andre

Here the equations, the problem is with the last function at the bottom of the sheet:

[ValeryOchkov]

[ptc-5419055]

Thanks for the answer but I don't understand what u mean... For what should the return value be used, is it really neccessary? I expected toggle(t) to switch between 1 and 0 depending on t. And that is what it does.

[Werner_E]

There may be other improvements possible (especially you may consider the use of the mod() function instead of the for-loop over nx) but it helps saving time if you dont calculate the same expression twice, especially as you do it recursive.

[ptc-5419055]

Thanks, with this i already save quite some time. However i wonder why your Version with mod doesn't end up with the same result.

[Werner_E]

However i wonder why your Version with mod doesn't end up with the same result.

This is because the routines using mod() yield 0 for multiples of the cycle time 1/f_T but we need a 1 here. This could be fixed but it doesn't matter if IA_Anker_AC is calculated differently as Andy has shown by getting rid of the recursion using precalculation of the cycle start values. You may use my toogle2() in his sheet as well or replace the call of toggle(t) in IA_Anker by that simple expression.

[Werner_E]

Strange effect: I tried to replace the functions toggle() and tx() by equivalent routines using the mod() function. They look the same, but nevertheless the result of I_Anker_AC() is quite different when used. Anybody a clue?

[AndyWesterman]

The very nature of the recursive procedure makes it very time consuming , especially if there are large numbers of cycles involved.

Cycle 1: takes 1 time unit.

Cycle 2: recalculates cycle 1 - takes 2 time units

Cycle 3: recalculates cycle 2; recalculates cycle 1 - takes 3 time units

...

so the time to run has a dependancy of 1/2(n)(n+1) on the number of cycles n

Add to that the toggle & tx functions have to iterate through every value of n, this probably adds another (1+n/50) type factor.

Overall the relation could be n^3 or n^4 law & getting very slow for even the 15 pulses ae the test case.

I've added various timing points to see where the delays occur.

suggestions:

1. Add a time range variable (tt) for the plots at the start (they are only for visualisation - no calculation is affected).

I think this reduuced the time for these stages from 20s to 5s on my machine.

2. change the toggle & tx functions

It may be possible to tidy this up further , but it seems to work.

3, Split the I_anker function into 2 portions.

The first calculates the starting current for each cycle (n) and saves the value in the I_anker_AC2.start vector.

The second then calculates each cycle based on the start value for the current cycle (no recursion)

additional changes to consider , if you add the t-n/f_T in the I_anker function the need for the toggle & tx functions may disappear.

with these changes the time to calcluate (for me) reduces from ~60s 15 Cycles to ~15s for 100Cycles

Regards

Andy

[Werner_E]

Find attached at the end of the sheet another way to do it without recursive function calls. Its a selfcontained function without the need of any auxiliary routines and does not require the range nx, so you are free at your choice of argument t. Thus I need to recalculate the "history" up to the point we want to evaluate for every call. I do this using a loop and the routine is speedy enough, I guess. Nevertheless Andy's solution with the precalculated values should be faster (haven't tested it, though).