A limit in Probuilder Loops?
- This topic has 14 replies, 7 voices, and was last updated 3 months ago by
.
-
What is the maximum number of iterations in a probuilder loop? According to my experience, 1000.If this is really the case, this is a very serious limitation, because the price series loaded in Prorealtime usually have several thousand elements, especially the weekly and daily ones.Has anyone else ever run into this problem
1 user thanked author for this post.
Try this:
DefParam DrawOnLastBarOnly=true
for i=0 to 2000 do
drawpoint(BarIndex-i,Close,3) coloured(255,0,0)
next
Return
I get the correct number of points on the screen.
For i=1 to 1000000
x=Close[i]
Next
Return x
The above works with max. 1000000 iterations…
1 user thanked author for this post.
This all makes no sense to me. The only thing possibly true is the false detection of the program being in an infinite loop, which could be true because the parser intelligently will try to find out whether things change in your code. For example an empty loop from 1 to x will show that message, because “why to perform that loop” is PRT’s thinking (not that it thinks, but PRT developers think).
To me, with the examples given, it is clear that one of the reasons to receive that error is the attempt to address bars beyond the amount present. For example, more than 1 million bars will never exist because PRT just don’t allow for them (200k for PRT Complete, 1 million for PRT Premium). Very, very theoretically, the PRT parser may have build in detections on loops that resemble this limit, because I seem to know how PRT development thinks. This 1M limit obviously makes no sense, depending on what you try to do. But for example, detecting this in nested loops which end up with a million iterations like 100 x 100 x 100 ? No. That is too hard to dig for me (the parser wont know about the 1m resulting iterations). But let the inner loop reference bars of 1 million more back, obviously still can’t be.
So MCG, it seems that you are referencing more that 1000 bars while only 1000 bars reside in your chart. That is, with your first post as a reference (but your last post does that just as well – see my last sentence at the end of this post.)
JS’ example with the DrawPoint will also be correct – is not related to bar data at all, but still runs into the PRT developers thinking that more than 1 million will be useless. It is not useless at all in this DrawPoint example …
It will be more complicated, because your examples, MCG, will be about several internal iterations, which you can not see but which will be there. For example, if JS his example is performed in random code, this code will be executed each bar. Whether 1000 bars appear in the chart or 20000 or 100000, each time the loop of 1 million is performed. And it will make no sense to do it … You can see this looking at the DefParam DrawOnLastBarOnly=true, because without that it will be a mess (which includes not getting a response from the cart because the calculations / plotting of 100000 x 1000000 (100 million) points takes too long.
Also, the DefParam directive looks nice in theory, but will cause havoc when ran on a live chart (which is updated in real time) because at each bar the plotting will be done and a bar can be one second. And since the ProBuilder code is called each tick, I would think it is even more messy in there than what the eye can see.The reference of JS to “memory slots” seems to be out of context and then makes less sense, but it does makes sense if it is observed in the context of Arrays, which you may use, MCG (but I don’t think you do).
because the price series loaded in Prorealtime usually have several thousand elements
So that. Load those/that in an Array – which you might be doing to begin with – and all bets are off because you might be doing this out of proper control; you might be doing that each call of the code (thus per bar shown in the chart) and it will be wrong to begin with. How that expresses ? well, adding 1000 elements to the Array which occurs more than 1000 bars and now the array exceeds its maximum elements which is 1 million …
So see ? all pieces of a puzzle, and in the end we might be doing it wrongly ourselves. But this is actually caused by the sheer impossibility to see what happens internally. This takes a lot of imagination and guessing; nothing of it is formally written anywhere. Not a single line in any manual. Ah, one written hint exists : an Array can hold 1 million elements. No wait, the Array can be addressed with an index to the elements, and that index number can not exceed 1 million.
BTW, MCG, are you using Arrays ? … LOL
But notice that the default number of bars in a chart is 1000. Coincidence ? So make that 2000 to begin with and see what happens.1 user thanked author for this post.
Close[1] is the closing price of the previous bar, not 2500 bars ago??
This is what I referred to, without being able to be specific. So Yes, that is true, but this is performed for each bar the code runs in to. Thus, we have a Close[1] calculated for the leftmost bar in the chart (say at -2499), we have one in the next bar (at -2498) and so on.
So IMHO the idea with a loop in PRT’s code, is never a good idea ? But it would be the intuitive thing to do. Side note : for Arrays loops are a necessity. But the base problem remains : you will do something with the Array based on bars. And that combines (invisibly) ugly. And then to think that in the Indicator code (not Strategy code) we are doing things per received tick, and can’t even see it. But we would know it and from there we may get our acts together.I think – but am not sure – that the design of the PRT coding environment has been made to avoid loops. Take the Summation command, for example.
The problems start when we want to write pixels to the screen, like in JS his example. Then things don’t combine. Then we must know what DrawOnLastBarOnly is actually doing. And why that is. And how we might need such a command for Strategy code just the same. But at some stage Arrays did not exist yet. Then the loops were partially useful only, and worked intuitively still fine in there. This stopped when Arrays came about and we can not see what we cause with our loops. Or how we keep on building the Array each bar, while one time surely is enough. But nothing is made for that …As we know, I am still learning too. 🙂
Edit : I see that JS has the better answer in his last post (crossed). But what I say here in my post is still in order as well.
Thank you PeterSt (and everyone who has been interested in my post) for your detailed analysis of the topic. Indeed, I use arrays in my program (which I have not shown in its entirety because it is excessively long). Actually, I have already solved the problem that brought me to the forum. It was motivated by an (unnecessary) double loop that multiplied the number of operations and led Probuilder to detect an infinite loop. Thank you, guys of the forum, for your kind and valuable cooperation.
This example will scan the last 200K bars and will plot that leftmost CLOSE on the chart:
1234567IF opendate = 20240719 AND OpenTime = 225900 THENFor i=0 to 200000x=Close[i]Nextdrawtext("#x#",BarIndex,highest[20000](high))ENDIFReturnI also used this indicator, on a separate panel, to know the BARINDEX value:
1RETURN BarIndex AS "BarIndex"This example just shows the number of empty iterations made (I started from 5K and ended up at 500M):
1234567defparam drawonlastbaronly = trueIF IsLastBarUpdate THENFOR i = 1 TO 500000000 //500M iterationsNEXTDrawText("#i#",BarIndex,highest[100000](high))ENDIFRETURNThe code creates a condition, when met, allows all the code to execute in the loop.
When condition not met, the CONTINUE command is called and loop jumps and continues from the start of the next iteration.
There’s probably a number of ways you could set something up like this.
Also, BREAK command terminates the loop when called.
I’ve wrote it like this so you can see the results when run.
Loop ‘i’ iterate 10 times 0 -9
‘a’ is incremeted when condition is true, when the remainder of i/5 = zero
‘b’ represent additional loop code but increment by 2 to give a different value to ‘a’ and not visually clash.
After 10 iterations of the loop, ‘a’ = 2 representing it executed 2 times. when ‘i’ was 0 and 5 .
‘b’ is double ‘a’ showing that it executed by same number of times.
Though the loop iterated 10 times, the code executed inside it was limited.
123456789101112131415a=0b=0for i = 0 to 9if i mod 5 = 0 then // only multiple of 5a = a+1elsecontinue // jump to next iterationendifb=b+2// ignored code if condition metnextreturn i , a,b4 users thanked author for this post.
You can also use the instruction “While” with a step of your choice…
1234567891011x=0xMin=0xMax=100Step=5while xMin<xMax doxMin=xMin+Stepx=x+1wendReturn x as "Number of Steps"5 users thanked author for this post.
Find exclusive trading pro-tools on 
