Sharpe-Ratio-to-pick-period-adaptively-based-on-time-frame

User-defined periods do not align very well with the concept of Scorecards. They are parameterless to be utilized across different tools: visualizers and optimization. Not to mention the challenge it brings, an extra input would be more likely to confuse users and unnecessarily overload the GUI rather than bring any improvement.

Eugene,

The Sharpe Ratio is a useful tool to assess the consistency of returns, but it must be "tied" in some way to the trading timeframe. If someone is developing a trading system which makes a 100 trades/day even a daily Sharpe has reduced value. While a realize that probably a large portion of the WL community develops trading systems using daily data, it is clear (based on numerous comments and questions posted) that not all do. My suggestion is an attempt to address a larger portion of the user base.

Vince

Maybe it'd make sense if the "tying" to the timeframe took place via an option in Preferences. Say "Sharpe: use adaptive returns" (inactive by default). So for EOD it could keep taking monthly returns and annualize them while a more suitable period would be picked for other timeframes accordingly. Note that here I'm not confirming that your idea makes sense.

QUOTE:
Note that here I'm not confirming that your idea makes sense.

Understand, but I think that you hit upon the key item in my suggestion:

QUOTE:
while a more suitable period would be picked for other timeframes accordingly

Vince

Now that we've agreed on having a more adaptive approach based on timeframe, let's rename the request to reflect the idea.

Eugene,

Does Adaptive = User Selected in your mind? I am suggesting a User Selected timeframe.

Vince

In my opinion, Scorecard would apply the right period based on backtest's time frame. Post #1 summarizes why user-specified parameter choices like this are suboptimal in Scorecards.

Understand...

How about a "default" adaptive period that the User can override?

Vince

Not saying that this is impossible to reach but in their current implementation (which I believe is perfect from both front and back end perspective), any override raises this conceptual and design problem expressed in Post #1.