Determine the charts time frame in a program

Forums ProRealTime English forum ProBuilder support Determine the charts time frame in a program

Viewing 12 posts - 16 through 27 (of 27 total)
  • #126788

    My platform is shut down at the moment so I can’t test anything.

    If you look at the Time Frame Detector code you will see that it needs x candles in a row where the time difference is exactly the same to confirm that that time difference is the time frame. By setting x as high as 20 you are asking it to find 20 candles in a row where the time difference between each candle is exactly the same. So in a 15 minute time frame that is 5 hours worth of candles. If there is some bad data or a holiday or a weekend in that five hour period then it won’t detect the time frame until at least 20 candles later. A lower number for x is easier to achieve but if too low then it comes with the risk of mistaken identity of the time frame. I generally found 6 to be a good compromise.

    Also in the code once the x candles with the same time difference has been met the value of mytime is fixed and cannot change again.

    #126818

    to help you to fix detector.

    – time frame in minutes work fine (x=6) .

    – time frame in hours work h1 x=6, but increasing hours in timeframe i need to decrease x. for example
    – for h2 timeframe i need decrease x to 5, because 6 doesnt work.
    – for h3 timeframe i need decrease x to 3, because 4,5,6 doesnt work.
    – for h4 timeframe i need decrease x to 2, because 3,4,5,6 doesnt work.
    – for h6 timeframe i need decrease x to 1, but detector fails because return a daily timeframe (4)

     

    ANYWAY, I REALLY DON’T UNDERSTAND WHY PROREALTIME DONT RELEASE A STATEMENT (LIKE OPENDATE, ETC) WHICH RETURNS CHART TIMEFRAME.

    IS A GENERAL ISSUE…

     

     

     

    #126821

    robocop -Please don’t shout in the forums. The use of all capital letters is considered shouting in any forum. Sometimes in the ProRealCode forums we use capital letters to highlight that a word is a code word but otherwise we try not to shout in the forums. Please don’t shout again in future posts.

    I don’t need to fix the indicator because as I said before it is totally dependent on the data that you put in as is every thing in life – what you put in effects what you get out. On v10.3 for me the indicator was able to detect the time frame on most popular markets within 6 bars. I have not extensively tested it on v11 but as I mentioned earlier I have found some issues in the open time of bars on my end of day version of v11 that would mess up time frame detection.

    In fact the indicator is no longer needed on v11 because we can use arrays to store values at any point in history and so create indicators that simulate MTF without the need for knowing what the time frame of our chart is. I have been testing today an indicator that I just coded that can show on any chart a simple moving average and standard deviation bands like Bollinger bands for monthly, weekly, daily and any hourly chart and any minute chart on any faster time frame chart without the need for knowing what the time frame of the actual chart is. It can also display lines that update on close as well as updating on every new bar. I hope to submit it and another version that shows the same result as a percentage of the bands to the library tomorrow. The same theory can be used to create other MTF indicators whilst we wait for PRT to be able to release their much awaited MTF indicator ability – the release of which has unfortunately been delayed by Covid-19 and the need to work from home.

    1 user thanked author for this post.
    #126824


    In fact the indicator is no longer needed on v11 because we can use arrays to store values at any point in history and so create indicators that simulate MTF without the need for knowing what the time frame of our chart is. …

    The same theory can be used to create other MTF indicators whilst we wait for PRT to be able to release their much awaited MTF indicator ability – the release of which has unfortunately been delayed …

    I’n not able enough to understand theory you describe, maybe you are right, but i am not sure that i can use an array to solve my problem, that i describe below:

    I have to calculate the number of bars in a theoretical 24-hour working day for my chart, in which user choice timeframe, and only way i’ve found is: 24*60/minutes of timeframe.
    For example, in the 15 minute time frame the number of bars in 24 hours is 96 (24 * 60 /15). Your detector is fine for me, because it returns a number of minutes (or hours) which i can use for a general algorithm.

    If anyone have any other way to reach target, i will appreciate.

    So, in a non capital letter to respect netiquette, i think that PRT developer have the chance to help user releasing general function that many people can use.
    To know which Timeframe is my chart, is in my opinion a basic function.

    Another basic and general function, that in my opinion is a must to have in a platform that have to deal the time factor, is a generalized routine to perform date operation.

    #126829

    All your suggestions can be posted here https://www.prorealcode.com/topic/centralization-of-queries-and-suggestions-on-prorealtime/.

    There’s no workaround till PRT add a new keyword to know the TF used and, hopefully, how many bars there are (theoretically) in a DAY.

     

    1 user thanked author for this post.
    #126831

    robertogozzi wrote:

    All your suggestions can be posted here….

    There’s no workaround till PRT add a new keyword to know the TF used and, hopefully, how many bars there are (theoretically) in a DAY.

    Thanks Roberto, i have placed a new post in the forum you showed.
    I hope that in the meantime we can find a way to indirectly derive the timeframe, optimizing the Vonasi procedure if necessary.
    for example, introduce a tolerance margin within which to consider the bar of the same duration as the previous ones.

    #126835

    I have to calculate the number of bars in a theoretical 24-hour working day for my chart, in which user choice timeframe

    Why not start a bar count at the start of a day when OPENDAYOFWEEK <> OPENDAYOFWEEK[1] and also a day count at the start of each day. Then if you get x days with the same bar count value that confirms that that is the number of bars in your day. In v11 this is very easy with arrays but in v10.3 you would have to have x separate variables and fill their values by adding a new one and dropping off an old one. Once all x variables are equal that is our number of bars in the day.

    #126842

    Why not start a bar count at the start of a day when OPENDAYOFWEEK <> OPENDAYOFWEEK[1] and also a day count at the start of each day. Then if you get x days with the same bar count value that confirms that that is the number of bars in your day.

    Good mornig Vonasi,

    follow this way i can obtain the number of effective operative bars in a day, in other words from Open Market Time to Close Market Time (for example from 9.00 am to 6 pm),
    but this is only first target i need to achieve.
    The second target is calculate the number (B) of the bar that would have been if then market had been open continuosly for 24 hour  (that i have definied “Theoretically” bars).

    I don’t have any ideas, for the moment, how to calculate B without know duration in minutes of a single bar.

     

     

    #126843

    This does the part of counting bars that actually exist and works in v10.3. Obviously it takes at minimum three days to establish a result. I’ll have to work on counting bars that don’t actually exist!

     

    #126861

    …I’ll have to work on counting bars that don’t actually exist!

    Yes,

    the way to go cannot be ‘counting’ in this case.in this ca se, the way is to derive what is “not countable” starting from what is known. but i have no idea actually.
    Thanks for your contibution.

    #126864

    This is as close as I can get after wasting far too much time on it. The issue we have is that as we get to faster time frames there isn’t always a candle where we would hope to find one so one day might have 288 candles in it and the next days 286 and then 270 and the same problem with counting how many candles in an hour. So the following works accurately on very liquid stocks on not very fast time frames only:

     

    1 user thanked author for this post.
    #126869

    This is as close as I can get after wasting far too much time on it. The issue we have is that as we get to faster time frames there isn’t always a candle where we would hope to find one so one day might have 288 candles in it and the next days 286 and then 270 and the same problem with counting how many candles in an hour. So the following works accurately on very liquid stocks on not very fast time frames only:

    Great Vonasi! I will try on when platform will go on (now under maintenance).
    In my opinion, PRT should let read some information about chart and market, (e.g. scheduled opening and closing times, timeframe, and so on).
    I am newbie in PRT platform enviroment, but I have some experience in other business development environments, and in my opinion PRT environment is poor about
    generalized functions that are normally available elsewhere.

     

Viewing 12 posts - 16 through 27 (of 27 total)

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