a) With multi country expansion we need to go with weekdays in things like strategy performance, and risk calculations since the database is involved.
b) To support users that strictly want bars I think all we need is a different ENGINE (or separate functions).
Offering a separate ENGINE that only works for single country universes requires the least effort for the user, but more maintenance for us. Offering alternate functions will require some rewriting for the users that do not use the default behavior (we can help automate). THere are pros & cons to each of course.
But the parties that care need to chime in and tell us . The more you tell us the more it will help us understand how to provide a solution
Where you really want bars?
Please list the formulas / functions where you want bars.
Is the difference with a) and b) clear and acceptable ?
A quick answer:
I have 65 custom formulas using price data by bars only-
The most frequently used functions affected by the bars/days debate are:
Hi,Low,Open,Close,BenchHi,BenchLow,BenchOpen,BenchClose,SMA,EMA,MACDD,MACD.
Only used once: Pr4WRel%Chg,Pr13WRel%Chg.
Of course, all of the factors in the Technical category can be thrown off a bit going to days…
Thanks. please see the updated main post. There are actually two ways to achieve the goal of providing a solution for each use case: 1) exclude holidays for single country universe only, or 2) include holidays for any universe.
I can’t predict all the ramifications of the approaches a and b, but at the user level a modification of the above existing functions with a new optional parameter to specify bars (default) or days would work. For instance, SMA(bars,[offset,series,bars]) where bars is 1 or 0 (for days). If the default assignment is an issue, maybe it could be user defined, (an account parameter?)…
After some out-of-the-box thinking with the dev team we think we discovered a NEW solution . It will allow us to leave the TA functions basically as they are from YOUR perspective. It’s a solution that does not require a time consuming, bug-prone, rewrite. It also does not introduce any performance penalties. There are still some headaches with this new approach, but it seems like the winner (unless we run into a roadblock that requires major rewrite)
We will also add specialized functions for doing TA including holidays. For example SMA2( wdays ), Close2( wdays ), etc. They will also re-use existing code. This is the opposite of what we were proposing before where YOU needed to update your systems to keep using bars. You will be able to continue writing your systems with bars even in multi-country universes if that’s your preference (although we don’t recommend), or use the new “weekday” TA functions.
I think this should please everyone.
PS. For the curious… We will have three versions of the stock prices instead of the current two. The main penalty of this solution is that it requires extra server RAM. Quite a bit actually.