Understanding Runtime Code Execution

Forums ProRealTime English forum ProOrder support Understanding Runtime Code Execution

Viewing 3 posts - 16 through 18 (of 18 total)
  • #196023

    Indeed there is still more in this one …

    The mistake I made is thinking that the “hit” just depends on the price, and when the price is met, you have the order (out or in). You actually steer us in the same direction with your last post. But it is different …

    Where it gets exciting is how the price is known at whatever level because *that* is what causes the trailing. Thus within your 1 hour etc. bar length there’s trailing up and it should be at the point or pip(ette) level (the minimum step of the instrument).

    If all the trades are known, the price changes are also known. And that is sufficient to do it (I think it is allowed to call that ticks). But this is different from forming bar sizes of e.g. 1 second or a tick (or 5 ticks etc.).

    In the end this also relates to the time (processing power) required to build all those bars, which are max 1million bars, regardless the length of them. Thus, PRT just limits it to 1M while more is available of course.

    Is this getting somewhere now ?

    #196784

    Hello, sorry for the late response. Been a bit busy.
    So I think I got the thing regarding tick data in backtests, but with the understanding of code execution I am still a bit unsure.
    Pls see this example:

    As you can see it is a super simple example, basically between 0900 and 1730 every 15minutes a long position is opened. At 1730 all open positions are closed.
    What confuses me is that it does buy a long position already at 0900 even though I declared flatbefore 0900, so this makes me think that the code is constantly running and constantly “calling” the “BUY” function, but as long as it is before 0900 the order is not accepted, but once it strikes 0900 the order is accepted even though it comes from the run regarding the 0845 bar.
    Am I correct with this assumption? If so this is a bit problematic, because by calling FLATBEFORE I actually plan on not including data updates from before 0900.
    Thank you 🙂

    #196791

    Your assumption is quite right.

    Put an If like this around all of your code (under the DefParam commands) :

    You won’t avoid the data updates with that, but your code will not execute as a whole. And what you want to execute after all, you put outside of that If.

    1 user thanked author for this post.
Viewing 3 posts - 16 through 18 (of 18 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login