| Pages:
1
..
5
6
7
8
9
..
17 |
ProbTrader
Junior Member
Posts: 16
Registered: 3-7-2018
Member Is Offline
Mood: No Mood
|
|
Hi
First of all, thanks Peter for unrivaled support of and dedication to GSB. You have a unique product (I have tried many, many platforms...) and its
great to see how quickly and in what direction GSB is evolving. As opposed to others out there, you can tell that this is largely driven by the users,
not just the developer. And also super important that the guy at the helm trades himself.
Having said that, one thing I belive would be very beneficial for the process would be the ability to control the IS/OOS periods in greater detail.
You currently have the option to set IS/OOS/validation as a %, and you can also play around with trd/No trd in the date window.
Now, if I am testing a system for 2000-2018, I may want the years 2001, 2008 and 2011 to be out of sample. Given this, I would want to see the
accumulated OOS results for these periods, and the accumulated IS data for the other periods (ie 2000, 2002-2007, 2009-2010, 2012-2018) so that you
can evaluate the system in a more meaningful way. Just to clarify, for the Spearman corr coef it could look something like this:
Period: Spearman:
IS (2000, 2002-2007, 2009-2010, 2012-2018): 0.998
OS (2001, 2008, 2011) 0.991
(The dates above are just randomly picked by me to illustrate this)
I have found that looking at different scenarios like this gives a lot of useful information. The point here is that you'd be able to see how the
results change when you put the systems under adverse pressure. For example, how has a short NG system performed during the last five heat waves? If
it performs well OOS for these dates it is a great vote of confidence that should make you much more comfortable with the negative tail risks etc.
Thanks.
|
|
|
cotila1
Junior Member
Posts: 78
Registered: 8-5-2017
Member Is Offline
Mood: No Mood
|
|
 
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
Sorry for the delay on this post
You can chose dates, and then choose weather to trade or not trade them.
then you can build systems. GSB will only look at the dates shown.
Then you can right click and change dates to non trade-able.
Then all the dates out of sample will be seen.
I'm lost on your spearman comment sorry. Spearman applies to walk forward only and is not applicable here. Spearman is only for comparison of WF data
over the same dates, but with the parameters varying.
 
|
|
|
ProbTrader
Junior Member
Posts: 16
Registered: 3-7-2018
Member Is Offline
Mood: No Mood
|
|
Thanks for your response Peter.
This is a good workaround, but it forces you to use the entire data set which you may not want to do. This also means that you don't have full control
over start and end dates, which, for example, is relevant for seasonal commodities and scenario based trading. An example of this would be NG. Winter
and summer contracts are different beasts, and should in most cases be treated as such (ie contract based and not as rollling nearbies - this is a
different subject of course). So if you are trying to construct a "NG winter system", you'd want the IS and OS to cover a specific date range for each
year, not the entire calendar year. The ability to specifically control IS and OS dates would allow this.
(Never mind the Spearman comment. It was there to show that it is useful to see ONE acccumulated number for ALL periods.)
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
Quote: Originally posted by ProbTrader  | Thanks for your response Peter.
This is a good workaround, but it forces you to use the entire data set which you may not want to do. This also means that you don't have full control
over start and end dates, which, for example, is relevant for seasonal commodities and scenario based trading. An example of this would be NG. Winter
and summer contracts are different beasts, and should in most cases be treated as such (ie contract based and not as rollling nearbies - this is a
different subject of course). So if you are trying to construct a "NG winter system", you'd want the IS and OS to cover a specific date range for each
year, not the entire calendar year. The ability to specifically control IS and OS dates would allow this.
(Never mind the Spearman comment. It was there to show that it is useful to see ONE acccumulated number for ALL periods.) |
You have 100% control of dates with this, but not in the context of walk forward. This however is just out of sample testing, not WF
|
|
|
ProbTrader
Junior Member
Posts: 16
Registered: 3-7-2018
Member Is Offline
Mood: No Mood
|
|
WF: yep - understand how this works.
OOS: In that case I must have misunderstood how the Trd/NoTrd logic works and how to control it.
Let me take an example to show why I am confused. Lets say I want to accomplish the following (never mind the reason, this is just an example):
- IS = 2001 and 2003 ONLY
- OOS = 2008 and 2010 ONLY
How would I accomplish this specifically? If I for example set the dates to 1/1/2001-12/31/2001 and 1/1/2003-12/31/2003 to "Trd", I will only see data
for 2001 and 2003. So far so good. But what's next? If I change the dates to "NoTrd" ALL other dates will be included in the output/equity curve, ie
ALL dates for which there is data, except 2001 and 2003. But I ONLY want to use 2008 and 2010 as OOS, and I want the stats to be the accumulated stats
for these two years ONLY.
I could obvioulsy save the systems and do a complete workaround where I re-run everything for a new set of dates with the systems that I choose. But
my point is that I want to be able to RUN the IS and OOS on specific dates without having to run sims twice and manually change this. I think the NG
example I mentioned above also illustrates this.
But perhaps I have completely misunderstood something here...
Thanks again.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by ProbTrader | WF: yep - understand how this works.
OOS: In that case I must have misunderstood how the Trd/NoTrd logic works and how to control it.
Let me take an example to show why I am confused. Lets say I want to accomplish the following (never mind the reason, this is just an example):
- IS = 2001 and 2003 ONLY
- OOS = 2008 and 2010 ONLY
How would I accomplish this specifically? If I for example set the dates to 1/1/2001-12/31/2001 and 1/1/2003-12/31/2003 to "Trd", I will only see data
for 2001 and 2003. So far so good. But what's next? If I change the dates to "NoTrd" ALL other dates will be included in the output/equity curve, ie
ALL dates for which there is data, except 2001 and 2003. But I ONLY want to use 2008 and 2010 as OOS, and I want the stats to be the accumulated stats
for these two years ONLY.
I could obvioulsy save the systems and do a complete workaround where I re-run everything for a new set of dates with the systems that I choose. But
my point is that I want to be able to RUN the IS and OOS on specific dates without having to run sims twice and manually change this. I think the NG
example I mentioned above also illustrates this.
But perhaps I have completely misunderstood something here...
Thanks again. |
Your asking something very unusual. You could hack the csv file to exclude periods, and then use the verify price data option with other dates in your
alternative csv file
|
|
|
ProbTrader
Junior Member
Posts: 16
Registered: 3-7-2018
Member Is Offline
Mood: No Mood
|
|
I am not so sure that testing systems for certain periods only (seasonality of contracts), and/or stress testing it for specific historical
periods/events is that unusual (I happen to know and have worked with many traders that do just that).
As I was alluding to above, I believe that this approach is preferred if you are developing systems on seasonal products, especially those where the
contract specs de facto differ between different months of delivery, I think anyone will miss out by treating all contracts the same way, essentially
as one continuous data series. Since they are different in their specs, have different fundamentals etc, they also have different price
behaviour/distributions/volatility etc. I guess one analogy I would make is with gold/silver. You may find a system that works for both - great if you
do as it is likely robust then - but realistically you are probably better off with two different systems. Another analogy would be to treat all hours
of trading the same for something like ES, which you concluded is a bad idea in your session time video (lthanks for putting together that video btw -
loots of good takeaways in it).
Also, for stress testing any system I find this to be a very practical approach (eg if a long only system survives the last 20 big drops OOS, it may
be a winner).
I realize that not all system developers think in these terms, but please do keep it under consideration during the develpment of the optimization
options.. Again, I find it superior to the current % settings for IS/OOS/Verification, and it is an addition I feel others would find useful as well.
(Also, I do understand that you can hack a CSV file, but there are obviously lots of issues with this. Not only is this inconvenent, but you would
have to transform the data as you end up with price gaps etc etc.)
Many thanks.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by ProbTrader | I am not so sure that testing systems for certain periods only (seasonality of contracts), and/or stress testing it for specific historical
periods/events is that unusual (I happen to know and have worked with many traders that do just that).
As I was alluding to above, I believe that this approach is preferred if you are developing systems on seasonal products, especially those where the
contract specs de facto differ between different months of delivery, I think anyone will miss out by treating all contracts the same way, essentially
as one continuous data series. Since they are different in their specs, have different fundamentals etc, they also have different price
behaviour/distributions/volatility etc. I guess one analogy I would make is with gold/silver. You may find a system that works for both - great if you
do as it is likely robust then - but realistically you are probably better off with two different systems. Another analogy would be to treat all hours
of trading the same for something like ES, which you concluded is a bad idea in your session time video (lthanks for putting together that video btw -
loots of good takeaways in it).
Also, for stress testing any system I find this to be a very practical approach (eg if a long only system survives the last 20 big drops OOS, it may
be a winner).
I realize that not all system developers think in these terms, but please do keep it under consideration during the develpment of the optimization
options.. Again, I find it superior to the current % settings for IS/OOS/Verification, and it is an addition I feel others would find useful as well.
(Also, I do understand that you can hack a CSV file, but there are obviously lots of issues with this. Not only is this inconvenent, but you would
have to transform the data as you end up with price gaps etc etc.)
Many thanks. |
I'm going to look into this more. Gaps are not an issue if you dont allow trading before 500 bars (1 month approx on 30 min 830 to 1500 session) to
occur after a gap
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by ProbTrader | I am not so sure that testing systems for certain periods only (seasonality of contracts), and/or stress testing it for specific historical
periods/events is that unusual (I happen to know and have worked with many traders that do just that).
As I was alluding to above, I believe that this approach is preferred if you are developing systems on seasonal products, especially those where the
contract specs de facto differ between different months of delivery, I think anyone will miss out by treating all contracts the same way, essentially
as one continuous data series. Since they are different in their specs, have different fundamentals etc, they also have different price
behaviour/distributions/volatility etc. I guess one analogy I would make is with gold/silver. You may find a system that works for both - great if you
do as it is likely robust then - but realistically you are probably better off with two different systems. Another analogy would be to treat all hours
of trading the same for something like ES, which you concluded is a bad idea in your session time video (lthanks for putting together that video btw -
loots of good takeaways in it).
Also, for stress testing any system I find this to be a very practical approach (eg if a long only system survives the last 20 big drops OOS, it may
be a winner).
I realize that not all system developers think in these terms, but please do keep it under consideration during the develpment of the optimization
options.. Again, I find it superior to the current % settings for IS/OOS/Verification, and it is an addition I feel others would find useful as well.
(Also, I do understand that you can hack a CSV file, but there are obviously lots of issues with this. Not only is this inconvenent, but you would
have to transform the data as you end up with price gaps etc etc.)
Many thanks. |
Programmer says
if we modify date from the left grid and tick “override original settings” from the lower grid
You can use this to have alternative dates like what your asking.
|
|
|
saycem
Junior Member
Posts: 48
Registered: 13-7-2018
Member Is Offline
Mood: No Mood
|
|
When sorting results I would like to be able to shift select multiple column headings so for eg you could sort by avg trade and then # of trades etc.
Similar to excel.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by saycem | | When sorting results I would like to be able to shift select multiple column headings so for eg you could sort by avg trade and then # of trades etc.
Similar to excel. |
I will look into it if this can be done.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by saycem | | When sorting results I would like to be able to shift select multiple column headings so for eg you could sort by avg trade and then # of trades etc.
Similar to excel. |
This will be done, likely in the beta builds in the next 2 weeks Im hoping.
Its a good idea. thanks for your contribution.
|
|
|
edgetrader
Junior Member
Posts: 24
Registered: 16-5-2018
Member Is Offline
Mood: No Mood
|
|
I was studying Rob Carver and one of his themes is to separate some of the fitting/optimization from the PnL producing trades. In GSB one way to do
this would be to target certain forecasting windows, e.g. 20 bars ahead or until the close of the day. Then the GSB output would be optimized with
something like RMSE against the correct target values taken from "future" price data. After this type of fitting, higher GSB output values would
correspond to higher predicted price moves over the next 20 bars. Another layer would then take over and translate the forecasts into entries, the
simplest being if output > X go long. One benefit would be that most of the fitting can be done on all in-sample bars even if the resulting system
only trades very sparsely in order to produce high avg trade.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by edgetrader | | I was studying Rob Carver and one of his themes is to separate some of the fitting/optimization from the PnL producing trades. In GSB one way to do
this would be to target certain forecasting windows, e.g. 20 bars ahead or until the close of the day. Then the GSB output would be optimized with
something like RMSE against the correct target values taken from "future" price data. After this type of fitting, higher GSB output values would
correspond to higher predicted price moves over the next 20 bars. Another layer would then take over and translate the forecasts into entries, the
simplest being if output > X go long. One benefit would be that most of the fitting can be done on all in-sample bars even if the resulting system
only trades very sparsely in order to produce high avg trade. |
This is complex and I dont understand the finer detail. I also dont know what rmse is. GSB does have separate trades via the PNL using nth and date
features. I think that is a great concept.
|
|
|
edgetrader
Junior Member
Posts: 24
Registered: 16-5-2018
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by admin | | This is complex and I dont understand the finer detail. I also dont know what rmse is. GSB does have separate trades via the PNL using nth and date
features. I think that is a great concept. |
Here's an example. The blue line is standard TS moving average with length 20 displace 10. This means it peaks 10 bars into the "future" to draw the
perfect line.
You'd give the 1bar momentum of that blue line to GSB as targets. If the line was 2808 a bar ago and now it's 2810, your momentum is +2. You'd want
the GSB output on this bar to be +2. If it's 0.5 you'd have an error of 1.5. RMSE is just a fitness function, you could use others.
https://en.wikipedia.org/wiki/Root-mean-square_deviation
Then once you're done with this, another layer would take the GSB output and go long if it's above +3, flat if below +1 (for example).
 
|
|
|
edgetrader
Junior Member
Posts: 24
Registered: 16-5-2018
Member Is Offline
Mood: No Mood
|
|
When GSB can build its own bars from 1min source data, a great feature would be to support MC custom resolutions. For example, add custom
range bars that calc the 20bar ATR on daily data and form a new bar if its high-low range, or open to close range as a variant, exceeds 5% of
ATR. Force bar completion at user specified session end e.g. 1500. Always evaluate at full minute ends and don't cut minutes into half or add prices
that weren't traded.
TS also has advanced bar types that in my testing however couldn't be used for systems as they all added phantom prices or peeked into the 'future' to
some extent. With MC you have control over the COM object's source code that's your custom bar plugin, so you could make advanced bars that are fully
backtestable.
https://www.multicharts.com/trading-software/index.php/Custo...
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by edgetrader | When GSB can build its own bars from 1min source data, a great feature would be to support MC custom resolutions. For example, add custom
range bars that calc the 20bar ATR on daily data and form a new bar if its high-low range, or open to close range as a variant, exceeds 5% of
ATR. Force bar completion at user specified session end e.g. 1500. Always evaluate at full minute ends and don't cut minutes into half or add prices
that weren't traded.
TS also has advanced bar types that in my testing however couldn't be used for systems as they all added phantom prices or peeked into the 'future' to
some extent. With MC you have control over the COM object's source code that's your custom bar plugin, so you could make advanced bars that are fully
backtestable.
https://www.multicharts.com/trading-software/index.php/Custo... |
I will run that by one of the experienced MC users. Some bars even on MC were not usable.
|
|
|
Gregorian
Junior Member
Posts: 97
Registered: 23-5-2017
Member Is Offline
Mood: No Mood
|
|
Advanced Bar Types
I've been working exclusively with Advanced Bar Types in MC and TS since just after GSB debuted. Here is a summary of what I've learned:
In TS, Kase bars are the only type that do not create phantom bars. TS' implementation of range and Renko bars always generate phantom bars.
Point-and-figure and Kagi bars are by definition completely unusable. Stick to Kase bars and you'll be OK.
In MC, Point Original bars (look them up - it's a hidden bar type, only selectable via the Command Line), Flex Renko (when configured not to generate
phantom bars), and the brand-new Kase bars in v12 are usable. I've had inconsistent results with Point bars, MC's version of range bars, therefore I
do not recommend them. So far I am having the best results with MC's Kase bars, for which GSB generates more strategies than it does for TS' Kase
bars. Clearly MC's implementation of Kase bars differs from TS', though I don't know how.
I've never experimented with developing Custom Bar Types. That would be a whole new world.
Note that with any of these, you must take into account gaps that can occur between bars. For example, there can be a 1 tick difference between the
close of one bar and the open of the next, so you should add at least 1 tick of slippage in the Report Slippage to get a fair idea of what to expect
in the real world.
I'm very grateful that GSB uses "on close" orders in TS/MC, as that is the only order type that works reliably with Advanced Bar Types. Competitive
products use "next bar at market", which makes some bar types unusable.
The advantage of Advanced Bar Types is that you can focus on price action better and thereby generate more profitable strategies. The disadvantage is
that there are so many more bars, that you cannot viably backtest for as long a duration. I believe the tradeoff is worth it. Others hold different
opinions.
|
|
|
JasonT
Junior Member
Posts: 61
Registered: 6-6-2018
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by Gregorian | I've been working exclusively with Advanced Bar Types in MC and TS since just after GSB debuted. Here is a summary of what I've learned:
In TS, Kase bars are the only type that do not create phantom bars. TS' implementation of range and Renko bars always generate phantom bars.
Point-and-figure and Kagi bars are by definition completely unusable. Stick to Kase bars and you'll be OK.
In MC, Point Original bars (look them up - it's a hidden bar type, only selectable via the Command Line), Flex Renko (when configured not to generate
phantom bars), and the brand-new Kase bars in v12 are usable. I've had inconsistent results with Point bars, MC's version of range bars, therefore I
do not recommend them. So far I am having the best results with MC's Kase bars, for which GSB generates more strategies than it does for TS' Kase
bars. Clearly MC's implementation of Kase bars differs from TS', though I don't know how.
I've never experimented with developing Custom Bar Types. That would be a whole new world.
Note that with any of these, you must take into account gaps that can occur between bars. For example, there can be a 1 tick difference between the
close of one bar and the open of the next, so you should add at least 1 tick of slippage in the Report Slippage to get a fair idea of what to expect
in the real world.
I'm very grateful that GSB uses "on close" orders in TS/MC, as that is the only order type that works reliably with Advanced Bar Types. Competitive
products use "next bar at market", which makes some bar types unusable.
The advantage of Advanced Bar Types is that you can focus on price action better and thereby generate more profitable strategies. The disadvantage is
that there are so many more bars, that you cannot viably backtest for as long a duration. I believe the tradeoff is worth it. Others hold different
opinions. |
Advanced bars are based on tick data? Is that right? I'm not sure about TS and MT but in Ninjatrader that is the case. Can you go back in time far
enough to do suitable IS/OOS backtest and then anchored walk forward? One of the key benefits I like about GSB (and minute bars generally) that you
can use data going back over a long period of time and test how a strategy would have worked in various markets.
Also I agree with avoiding 'virtual' bars like renko, range bars etc where they fill in gaps to make the chart look nice. You get massive disparity
between backtested results and live trading, because of the slippage.
Thanks for sharing your findings.
|
|
|
Gregorian
Junior Member
Posts: 97
Registered: 23-5-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by JasonT | | Advanced bars are based on tick data? Is that right? I'm not sure about TS and MT but in Ninjatrader that is the case. Can you go back in time far
enough to do suitable IS/OOS backtest and then anchored walk forward? |
Yes, in order for Advanced Bar Types to produce replicatable results, you need to base them on tick data. In both TS and MC using 1 tick data is
mandatory for some Advanced Bar Types and optional for others.
TS provides 6 months of tick data. In MC it depends on the data provider; IQFeed provides 6 months, others can be less. With 6 months of tick data,
that can be hundreds of thousands of bars, depending on the Advanced Bar Type, so it's a lot of data. But it's not a very long time period, hence the
tradeoff.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
I'm going to talk the bar types over with the programmer when we come to rebuild the data manager. I would like feedback if any other GSB users want
the feature.
|
|
|
JasonT
Junior Member
Posts: 61
Registered: 6-6-2018
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by admin | | I'm going to talk the bar types over with the programmer when we come to rebuild the data manager. I would like feedback if any other GSB users want
the feature. |
Depending on your data provider you get 360 days of tick data with Ninjatrader. You can buy up to about ten years of historical tick data for some
instruments for ninja with some online providers.
Despite the large number of bars that you can get in a 6 month or 360 day period, for me that is insufficient time (years) to capture enough different
types of market conditions and prove system resiliency. I've produced (without GSB) a lot of different volume bar based strategies for ninjatrader,
and have only been able to back test over 360 days. None of them passed by incubation testing. Perhaps the strategies were bad, or perhaps there was
not enough data to test them adequately. Maybe both.
Further I note that you need to be really careful about time stamping of each tick of the tick data - ie the data provider must use it and you've got
to ensure that your historical tick data is time stamped in the same way that your live tick data is. Otherwise your back testing will be inaccurate.
I've seen volume charts on two different computers (one on a VM in the US and one on a PC in Australia) and, for the same instrument, the volume bars
build differently. This was due to the different sequence of arrival of the ticks due to IP routing and long trip times. Refreshing the charts fixed
the problem, but this is something that needs to be considered for unsupervised auto trading.
For those reasons my preference currently is to use minute based bars and many years worth of data for in sample and out of sample testing.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by JasonT | | Quote: Originally posted by admin | | I'm going to talk the bar types over with the programmer when we come to rebuild the data manager. I would like feedback if any other GSB users want
the feature. |
Depending on your data provider you get 360 days of tick data with Ninjatrader. You can buy up to about ten years of historical tick data for some
instruments for ninja with some online providers.
Despite the large number of bars that you can get in a 6 month or 360 day period, for me that is insufficient time (years) to capture enough different
types of market conditions and prove system resiliency. I've produced (without GSB) a lot of different volume bar based strategies for ninjatrader,
and have only been able to back test over 360 days. None of them passed by incubation testing. Perhaps the strategies were bad, or perhaps there was
not enough data to test them adequately. Maybe both.
Further I note that you need to be really careful about time stamping of each tick of the tick data - ie the data provider must use it and you've got
to ensure that your historical tick data is time stamped in the same way that your live tick data is. Otherwise your back testing will be inaccurate.
I've seen volume charts on two different computers (one on a VM in the US and one on a PC in Australia) and, for the same instrument, the volume bars
build differently. This was due to the different sequence of arrival of the ticks due to IP routing and long trip times. Refreshing the charts fixed
the problem, but this is something that needs to be considered for unsupervised auto trading.
For those reasons my preference currently is to use minute based bars and many years worth of data for in sample and out of sample testing.
|
Im very sympathetic to your comments. Can we do some custom bar types with 1 minute data instead of tick? It might resolve most of these issues.
|
|
|
edgetrader
Junior Member
Posts: 24
Registered: 16-5-2018
Member Is Offline
Mood: No Mood
|
|
Thanks for the interest and comments on this idea. With Kase bars in TS, you can set them to a target range of 2 points and have them built from 1
minute data. The only issue I found in my testing is that TS peeks one bar into the future to construct the bars. For example, your current bar has a
range of 1.75. The next minute bar that comes in has a range of 2.50. TS uses future knowledge to complete the current bar at 1.75 and build the next
bar with 2.50.
The correct thing to do is leave the current bar open at 1.75 and wait for the next minute to complete, then make a bar with 4.25 range. The
occasionally larger bars like this one with 4.25 range are what you have to accept when correctly building advanced bars out of 1min data. The big
advantage will be that most GSB users have access to up to 20 years of 1min data and systems can be live traded with MC custom resolutions.
|
|
|
| Pages:
1
..
5
6
7
8
9
..
17 |
![[*]](images/davis/default_icon.gif){kind=icon}
