TIMEFRAME AS A VARIABLE
Forums › ProRealTime English forum › ProOrder support › TIMEFRAME AS A VARIABLE
- This topic has 9 replies, 3 voices, and was last updated 3 years ago by
PeterSt.
-
-
08/07/2022 at 12:21 PM #198668
Hi again,
many thanks to all those who replied to my previous question.
Now I’ve another question: why it’s not possible to state the minutes/hours in timeframe command as a variable, so the system will find the best timing ???
I saw on youtube that other trading programs will allow it.
Is there any trick to solve this matter without continuosly trying many backtests to find the bst timing ???
Many thanks for your replies.!!!
08/07/2022 at 12:27 PM #198669If only that could be so …
I always thought that it will be too difficult for PRT development to make that; it is very much related to how all works within the PRT programming language. It would require a (too ?) huge overhaul.
1 user thanked author for this post.
08/07/2022 at 12:32 PM #198671Yes I do it often.
Set in the Optimiser min = 000000, max = 230000, step = 010000.
Above will (quickly) give you the optimised hour then narrow it down as, for example … 140000, 150000, 000500 to get to optimised 5 minutes.
Flat Before / Flat After can’t be optimised.
08/07/2022 at 12:35 PM #19867308/07/2022 at 12:39 PM #198674math regarding crossings
Who mentioned crossings?
simpler than I envision ?
Must be as I’ve never had any problem, I’ve been doing it for years! 🙂
08/07/2022 at 1:16 PM #198677@ Grahal
thanks for your reply but I can’t understand how to do it.
My goal is to find a way to substitute the number (60 minutes in the below example) with a variable (let’s say TF1) and let the computer to find the best TF for that system.
“timeframe(60 minutes, DEFAULT)” changed into “timeframe(TF1 minutes, DEFAULT) ”
Is your the way to sort it out?
08/07/2022 at 1:20 PM #198678Hahaha or maybe that should be DOH (to me! ) … I’ve just read your question again!!
I thought you were asking about optimising TIME (not Timeframe).
Apologies, I must slow down, IIII Mmmuuusssttt ssssllloooowwww ddddoooowwwwnnn! 🙂
08/07/2022 at 2:05 PM #19868308/07/2022 at 3:01 PM #198695You could try using …
If Time = XY and BuyCond Then
Buy at Market
EndifThen optimise Time as I described in my erroneous post, then at least you will know if an exact Hour or 30 min or 15 mins, or 5 mins or 1 min is the optimum than you can set this (5 min or 1 min etc) as your Timeframe command?
I’ve never done above, but I will try it later as I just thought of it! Or is the heat still getting to me!!?? 🙂
Let us know how you get on?
1 user thanked author for this post.
08/07/2022 at 4:50 PM #198715Then optimise Time as I described in my erroneous post, then at least you will know if an exact Hour or 30 min or 15 mins, or 5 mins or 1 min is the optimum than you can set this (5 min or 1 min etc) as your Timeframe command? I’ve never done above, but I will try it later as I just thought of it! Or is the heat still getting to me!!?? 🙂
Haha, I see no difference with your first post about this, so my response will be the same and won’t need a repeat.
Now see emphasis in the quote above : Yeah, that could do something. But it is not related to what MTF is normally used for (like you say it yourself, you can always do *that*) plus I don’t think you will be able to make real money over this.
TimeFrame is about setting the bar lengths such, that all math you apply by means of PRT functions (Average, RSI, 200 more) apply to that set TimeFrame.
It could be mimicked by some smarter code which grabs the output of bars at e.g. 15 minute intervals and skips which happened in between and then apply an e.g. Average(MyClose[14]) but this is not even easy to make (will require a lot of looping and arrays could be useful).
It could be worthwhile so set up something like that, even if it takes a month. I suppose this month will be won back within a next month, as the testing everything within a new TF is an enormous redundant job which could be automated.
In the end this will fail because of too many references to e.g. MyVariable[2]) and MyVariable now needs a “MyClose” too (which is what it comes down to).I suppose PRT better had created from the start a syntax like this :
TF10m->Close[2]
TF5s->Close[2]And with some indirection support (or macro substitution or whatever similar technique) we could have made that
@MyTF04->Close[2]
@MyTF01->Close[2]But then some PRT guy (or Roberto) will tell that this requires strings in variables, so that we can do this first :
MyTF01 = “TF5s”
MyTF04 = “TF10M”but that PRT by now is too old to make such a radical change. So, stuck.
Still the support for MTF I deem great. Working with it can be a hell (think about the If commands not allowed and more hoopla we al ran into). I take it that this does not require elaboration.
-
AuthorPosts
Find exclusive trading pro-tools on