This may have been asked before but my searches in the forums haven't turned up anything.

Is there a way to get access to data normally displayed in the performance tab such as profit factor, number of trades (long/short/total), Sharpe ratio as of a particular bar. Some strategies work well on some stocks and not on others. I'd like to take trades where to date the system is profitable.

I realize there is a dilemma of sorts. If you don't take a trade because the past trades have been poor and that trade ultimately boosts the profit factor, for example such that you would end up taking the next trade, it wouldn't be in the results because you haven't taken it!

Is there a way to simulate a strategy where you have all the results of every trade and then go back and apply this kind of filtering?

I can see writing the unfiltered results to a file and then writing a program to filter and generate the new performance stats but then you lose all the analytics of WLP

In Wealth-Lab 5/6, you can't officially access the equity curve (Sharpe ratio, profit factor etc.) in a Strategy. These metrics produced by the various performance visualizers are applied when Strategy has already completed executing. However, we've developed a Community Components-driven solution that works to some extent (but isn't precise):

WealthScript Techniques | Interacting Dynamically with Portfolio Level Equity

The idea is to obtain the Strategy's SystemResults/SystemPerformance objects (for more see the API reference > Performance Visualizers) by using some sort of a workaround. Using the equity/performance data contained by these objects, you can re-create any performance metric e.g. Sharpe ratio. A good helper in this affair will be the MS123 Visualizers library's open source code:

Home - MS123 Visualizers

Specifically, have a look at PerformanceEngine.cs. I mean, the first link is a power tool but it's your job to code all the performance metrics you're interested in. Borrow some code from MS123 Visualizers -- stuff like Sharpe, profit factor, number of trades etc. already exists there ready for reuse.

Sadly, the discussion was broken up and continued in (an essentially duplicate) new thread:

Accessing SystemResults

Of course this is not going to help anybody keep the forum organized (if only we had a Combine Topics feature), but I'm leaving here this pointer so that anyone looking for related topics could find them more easily.

I'd like to run a strategy on a set of 100 symbols (Fixed dollar, portfolio simulation mode)

I have two goals

1) I'd like to write some results for each symbol that are found on the Performance or Performance+ tabs to a file. (I can do the calculations)

Should this be done in a Visualizer, Position sizer, or somewhere else? I will need to access the equity curves for each symbol. In this way, I can assess whether a strategy works well on each symbol in the dataset and do some quick sorts on the various stats. Is this possible?

2) If I can do the above, I plan to write a Position sizer that says if a strategy run this way (fixed dollar) has at least "n" trades so far, use the Sharpe ratio or Profit factor, up to the point of the current alert to modify the size of the trade. So if a strategy has been performing poorly based on some criteria starts fairing better, I can brgin increasing the size of the position.


I guess the basic question is can I run a set of symbols, generate the equity curve for each, access them individually, and perform some of my own calculations (or even access the results (not the methods themselves) that WL already produces) so that I can write them to a .csv file

It was mentioned here /Forum/Posts/Accessing-SystemResults-32290 that "Interacting with the Equity Curve" is not the way to go though I am intrigued by what you said in the last post

QUOTE:
I finally found a solution to this problem and will include it in the next release of Community Components (March 2012). Finally, then we will consider it out of beta!

#1) This could be done in a Visualizer.

A. First, Strategy finishes executing all possible trades in RP mode with 1 share.
B. It's turn for PosSizers to be applied, now in Portfolio Simulation mode, ruling out all signals impossible to take due to capital constraints etc.
C. Finally, Visualizers get the complete equity curve and system performance in portfolio simulation mode.

With C.Components 2012.03, "Interacting with the Equity Curve" becomes a reliable technique, enabling to implement this mostly w/o having to resort to a Visualizer.

#2) Why not? It's possible to filter signals and/or adjust the position size based on a system's performance like we did in our Percent Winners position sizing (% Equity) or Trading the Equity Curve. Note that Wealth-Lab does not provide individual symbol's equities and/or performance metrics to Visualizers/PosSizers, so you'll have to build these curves/metrics yourself in your PosSizer (if that's possible).

Thanks for the help Eugene

It appears at first blush, that I am better off waiting for the new C.Components. Is there an ETA? March is only days away.

Can you clarify

QUOTE:
PosSizer (if that's possible)

If the new components let me do the required calculations, e.g. calculate say, the daily profit factor for a strategy from the start of the period, up to the day before, couldn't that information be passed to a Visualizer/PosSizer for it to use? I'll re-examine the code for Percent Winners. Where or Why would this be impossible?

It might make more sense to calculate the daily profit factor right in the PosSizer. It's a pretty simple calculation and all the required data are there.

FYI

As Community Components 2012.03 has been released, "Interacting with the Equity Curve" has finally become more reliable than ever before. Right now, it's not compatible with customized commission plan values (the default values are applied instead). However, all previous issues like the missing stop/limit trades are now gone.

Important note to the users of the PerformanceEngine class (internal, unsupported part of the MS123 Visualizers library):

The information regarding PerformanceEngine calling conventions provided across the forum before is actual as of the library version 2012.05.1 and earlier. In future versions, the syntax will most likely undergo a breaking change due to a complete rewrite of the PerformanceEngine class.