but if you try to calculate a more complicated indicator like macd or stochastics, for some reason the calculations aren't correct when you try to use the calculation in an if-then-else expression or use the def variable (with the higher aggregation period) in another calculation.
ah...this can sometimes get quite complex - especially if you are developing a general solution to handle all cases.
anyways, so let me see if i get this. say you are doing an average. its the same in principal for stochastic or any other indicator so lets take the average as an example. for the sake of example, lets say we want an average of closing prices.
so your algorithm might look like this:
1. decide where to start the aggregation - on the first bar of the chart might be one possibility. another, more logical to me, might be to always start on a round hour / or 30 min or 5 min - depending on the granularity.
2. next keep a rec variable that holds the closing price after each granularity period and zero otherwise. so for example:
say you are doing 30 min aggregation on a 5 min chart.
closing price on the 5 min chart over the last 7 bars: 1, 2, 3, 4, 5, 6, 7, 8 ,9, 10
your rec variable over this period might look like this: 0, 0, 3, 0, 0, 0, 0, 8, 0, 0, etc.
3. on each time the study is called, you check the time of the current bar. if it is the end of your aggregation period, you store that value in the rec value for this iteration. if it s not the end of the aggregation period, you just put there zero.
4. now, you calculate the average - so for a simple average, you would iterate over the rec variable going back to "length" number of non zero values adding them up and dividing by length.
once you get this down, there are optimizations you can do to this but i wouldn't get into them till i have something that is working as basis first. besides, it might run fast enough so that you don't need the optimizations.
I guess it can get a little complicated. I'm not very good with think script and wouldn't know where to start with something this tricky. I wish the calculation issues I mentioned earlier wrt using a def assignment from a different aggravation period was fixed. Writing a mtf indicator would be much easier. Is writing mtf indicators much easier in other platforms?
i mostly have experience with ToS and SierraChart and a little bit with NT. my 2 cents is that your experience with ToS is similar to the others meaning:
they provide a pretty easy and straightforward way to implement mtf indicators. if you go down this path it is pretty straight forward. this does come with a price in performance though. this price is usually because they implement a general solution to handle all cases that users might require. you can try and improve the performance by implementing it directly on your own (like you are thinking). you improve on performance cuz you can build something very specific and optimize it for your requirements - but that becomes a bit more tricky as you need to understand exactly how the mtf works and all of the outlier cases.