Try to analysis the historical trades after backtesting, however I have to manually save trades into a text file. Is it possible to save all the trades into a specified text file by a strategy? Thanks.

Of course it's possible. Give this routine from Community Components a try:

SaveTrades

However, I just wonder what's the point in analyzing trades when Wealth-Lab has performance visualizers for every taste?

Thanks for your answer. It is amazing!

The Trade Graphs (Performance visualizer) is not great as I expect. In this extension, Win%+ Profit Factor are provided, but I need Avg Profit% and Payoff Ratio as well. Second, It shows above lines without moving average. Third, this is the most important. The whole testing period can not be showed as a bird view, a certain period can not be zoomed. Or, simply say, it is not flexible as I need. At last, if trades are over 20000, trade graph are showed very slowly.

Currently I trade based on signals from EOD data, it is difficult to manually trade at open price, I have to write a program to execute trades. I have several strategies based on several datasets. Before market is open, I have to make decision manually to apply the strategy based on its average profit% is greater than its SMA(20). Currently I analysis it on Excel. Trying to make it simpler.

Not sure if my answer is clear since it is a little bit complicated plus my poor English. Thanks for your ask. I wish WLD could be better and better

One sudden question, how to get the equity curve data based on trades? I can write codes but try to get a simple solution. Is there any functions like SaveTrades you showed above? You've been very helpful. Thanks so much.

QUOTE:
One sudden question, how to get the equity curve data based on trades?

I've no idea what the trade-based equity curve is. By chance, is this what we know as Closed Equity?

QUOTE:
The Trade Graphs (Performance visualizer) is not great as I expect. In this extension, Win%+ Profit Factor are provided, but I need Avg Profit% and Payoff Ratio as well. Second, It shows above lines without moving average. Third, this is the most important. The whole testing period can not be showed as a bird view, a certain period can not be zoomed. Or, simply say, it is not flexible as I need. At last, if trades are over 20000, trade graph are showed very slowly.

1 - I'll enter your request in our backlog for future evaluation. Making no promises as this might be a considerable effort.
2 - Win Rate % and Profit Factor itself are the moving averages. The window for averaging is in the upper left corner: type in your value in the Lookback field (30 trades by default).
3 - For some reason, I never planned to make the graph zoomable. I'll enter your request in our backlog for future consideration.
4 - Actually, Trade Graphs is not one visualizer: it's a set of 5 visualizers running together in parallel. When one executes an enormous backtest with 20K+ trades, some slowdown should naturally be expected compared to normal backtests with hundreds or thousands trades. While I can assure you that every effort was made to make the PV code work fast, the control it's using may not deliver optimal performance itself under heavy load.

Yes, Closed Equity is what I want. Thanks so much.

As regard to the point 2 you mentioned above, what I need else is Avg Profit, which equals to avg profit (based on profitable trades) * win% + avg loss (based on loss trades) * loss rate. I need moving average for this indicator and win%. It is very important for short term trading system.

Thanks for your answer and your effort to improve WLD.

QUOTE:
I need moving average for this indicator and win%.

Perhaps you overlooked my earlier comment. Therefore let me quote my reply #4:

<<2 - Win Rate % and Profit Factor itself are the moving averages. The window for averaging is in the upper left corner: type in your value in the Lookback field (30 trades by default).>>

QUOTE:
3 - For some reason, I never planned to make the graph zoomable. I'll enter your request in our backlog for future consideration.

I just looked into it and can say that I was wrong. The graph already is zoomable so no action is required. I just completely forgot about it. ;)

To zoom in on Win % Rate / Profit Factor chart, click and hold your left mouse button anywhere inside the lower pane (Profit Factor) and then drag towards right. Just don't click on the PF curve itself as doing that would take you to a particular Position on the chart. Special buttons will appear to zoom out.

Hope that helps.

tradercn,

It does not make sense to display rolling Payoff Ratio as its shape resembles already existing Profit Factor very closely:

Profit Factor = Gross profit / Abs(Gross loss);
Payoff Ratio = Abs(sum of average profit % / sum of average loss %);

So in upcoming update, I'll add rolling Avg Profit % to the Trade Graphs visualizer as you requested. Consequently, the "Win Rate + Profit Factor" tab will be renamed.

I have a couple simple requests for the Rolling Performance Metrics tab plots. They're illustrated on the attachment.

1) Could you add a parallel date scale (center of date range) to the horizontal axis? Or is that hard to do?

2) Could the Profit Factor scale be made logarithmic? (I'm not sure why its in 1000s; lots of profit there. The large PF values do correspond to high Win% values, so that makes sense.) The average %profit of this strategy for this dataset is 4.15% over 800 daily bars. This is a buy-high strategy, so it tanks when the market is down.

3) Please fix the cut-offed title in the first plot.

Also, the Risk/Rewards tab for Trade Graphs shows blank plots. Can you reproduce that?

QUOTE:
Also, the Risk/Rewards tab for Trade Graphs shows blank plots. Can you reproduce that?

To start using the Risk/Reward graph please read its online user guide in the Wiki. As with most everything we do, a prerequisite in the code of your strategy is documented there (see Notes at the bottom).

QUOTE:
3) Please fix the cut-offed title in the first plot.

I've been aware of this cosmetic bug. Workaround: simply maximize the Strategy window (or maybe resize to make it fit the title).

QUOTE:
1) Could you add a parallel date scale (center of date range) to the horizontal axis? Or is that hard to do?
2) Could the Profit Factor scale be made logarithmic?

Sorry but the complexity of implementation of these single-user features will not justify the potential compatibility issues. The PF of this backtest is too enormous for the mainstream.

QUOTE:
To start using the Risk/Reward graph please read its online user guide in the Wiki.

So I need to define RiskStopLevel values in the strategy code first before I can use the Risk/Reward graph. Got it.

QUOTE:
3) Please fix the cut-offed title in the first plot.

QUOTE:
Workaround: simply maximize the strategy window (or maybe resize to make it fit the title).

The provided screenshot already has both the strategy window and WL application maximized as much as possible under Windows 7.

QUOTE:
1) Could you add a parallel date scale (center of date range) to the horizontal axis?...
2) Could the Profit Factor scale be made logarithmic?

QUOTE:
the complexity of implementation of these ... features will not justify the potential compatibility issues.

I don't follow. What compatibility issues? Are users exporting these results to other apps? How is that done?

QUOTE:
The PF ... is too enormous for the mainstream.

I really don't follow. Are you saying too few understand the importance of this analysis? One of the things I like about Fidelity is their willingness to try to educate investors because investing is complicated. Perhaps some videos illustrating how Profit Factor can be used would be helpful or an Investopedia link.

BTW, all the WL wiki external links to TSSF (Trading System Safety Factor) are broken. But I was able to find Mikhail Korolyuk excellent article "Be In-Phase" about TSSF on the WayBack Machine here: https://web.archive.org/web/20140210034343/http://championship.mql4.com/2008/news/366

I searched other places for TSSF in active websites, but can't find anything. Perhaps someone could write a Stocks and Commodities Magazine article--which features Wealth-Lab.

Thanks for the heads-up, I've updated the TSSF link to point to the WayBackMachine's archived version of Korolyuk's work. Nice idea about a S&C article on TSSF.

We will have to live with the Rolling Performance Metrics visualizer's appearance such as the minor cosmetic issue with the title. Neither I plan to introduce logarithmic scale (which isn't required for the absolutely majority of backtests) nor a secondary date scale. These extra features are not and will not be highly requested, and I prefer simplicity to single-user solutions. 'Compatibility issue' was a poor choice of word - I rather meant that in my past experiments with the PV code, similar changes had an adverse effect on the visualizer's user experience / stability.

On the attached Profit Factor plots, the profit factor called out in the tool tip has nothing to do with what's plotted on the graph. What's interesting is the x-axis (Position) looks right on the tool tip; it's just the y-axis (Profit Factor) that's wrong on the tool tip.

This makes me wonder how reliable these Profit Factor plots really are. :(

Let's quote the Wiki online user guide, the first and the last sentences of it with key fragments highlighted:

This view presents a chart of rolling Win Rate %, Average Profit % and Profit Factor on a single graph.

As with other performance visualizers, mousing over the lines will display a tooltip with the position number and an associated value (Win Rate or Profit Factor).

The graphs show rolling values and the popup displays the individual value. That's the difference. Double click on a Position to get to that trade.

QUOTE:
The graphs show rolling values and the popup displays the individual value. That's the difference.

I thought the tool tip gave the "average" like the plot does. But now I realize it gives single Profit Factor value for a specific position. Thanks for the clarification.

Something is still not right with these Profit Factor plots (attached above). These attachments for the Profit Factor are suppose to be averaged over 30 positions, yet they have sharp spikes in this average. How is that even possible? Even if we had 30 positions in a row with profit factors over 200, one would expect some roll off to each side of that event. But we just see a single "average" spike without its "skirt". This behavior mystifies me in an "averaged" or smoothed plot. Perhaps we aren't dealing with a "moving" average of 30 positions as I'm assuming.

I guess I should be studying the source code to figure this one out. Obviously, I'm missing something big time here.

Indeed your plots don't look usual to me, and the PF values are suspiciously high (yet in post #8 you said it's fine). With these spikes it doesn't appear "averaged" as usual: the graph should look smooth as in the Wiki example. I think it has to do with your trading strategy's profile. If I could reproduce it following a step by step procedure I'd tell if this is wrong or right.

Well, I had the brilliant idea of setting N=1 for the moving average, and I got nothing. Setting N=2 gives me a horizontal line. Can you reproduce that? Is that normal?

Anyway, setting N=3 is reproduced in the attachment. This is the same strategy and dataset used in Post# 12 where N=30. The Win Rate is quantized, which is bogus. The Average Profit looks fine.

If the strategy itself is to blame, then there's a dynamic (heap) memory failure. But this is my production strategy, and it works well--no problems. If there are overruns in .NET collections, don't you get a run-time error (w/default compilation switches)? I would think if there were serious coding problems in a production strategy, it would be erroring all the time.

I'm assuming if you let N=3 on your strategy, you don't see any quantization of the Win Rate ... correct?

I find it hard to explain the difference between your results and mine. Would including the GC request:

CODE:
Please log in to see this code.

at the end of the strategy be a problem? Maybe the GC messes up the heap for visualizers.

Maybe this problem isn't worth our time to troubleshoot unless someone else can reproduce the problem.

N=1 will not work; the lowest average period allowed is 2. If you see the quantization of Win Rate or get a Profit Factor too big, in both cases just bump up the lookback period - for example, from 30 to 50 or even more. The rolling PF numbers on your charts are bogus and should be orders of magnitude lower - more in the ballpark of 1 to 10-20 like on the sample chart. They should get there after increasing the lookback.

There are no "heap failures" or "overruns" at play here but the rolling stats algorithm may need a closer inspection. I'll put it on my todo list to take a look it later.

1. As to spikes in the Profit Factor, this doesn't prove to be an issue. Explanation is simple: it happens when your system has a pretty high win rate (e.g. a winning streak) within a short lookback period of X (e.g. 3-15 trades) and the gross profit over these X trades is much greater than the gross loss.

Example: 3 trades, 2 wins with $20,000 profit and a $(500) loss = a Profit Factor of 400.
Solution in post #18 holds true: choose an adequately high lookback period to not be affected by the outliers (e.g. 30-50 should do).

I've found a couple cosmetic bugs with the rolling stats algorithm:

2. The actual lookback value is currently = (lookback - 1). Workaround: increase the lookback period by 1 if you wish to see the correct graph (e.g. for a 30 lookback set the value = 31).

3. Another bug is the bogus "quantization" seen in your post #17 which affected small lookbacks (e.g. 2-3). Problem is, the win rate % there never reached 0. Thanks for spotting this!

#2 and #3 are to be fixed in upcoming build v2018.09.

QUOTE:
1. As to spikes in the Profit Factor, this doesn't prove to be an issue. Explanation is simple: it happens when your system has a pretty high win rate (e.g. a winning streak) within a short lookback period of X (e.g. 3-15 trades) and the gross profit over these X trades is much greater than the gross loss.

So the lookback period is in trade units and not bar units. I never knew that. You might add a "#of trades" label to that control.

This is a buy-high strategy, so when the market spikes up there can be tons of winners. That's normal and expected. But I never thought about the Profit Factor spiking without shirts around the bottom. However, wins are a non-linear behavior. Perhaps it makes "some" sense not to have a skirt.

I got into this because buy-high strategies (which I employ) become very problematic in a down market. So I thought about trying a PosSizer (for the first time), and the TSSF (Trading System Safety Factor) was the PosSizer I was eyeing. And I was using the win% visualizer to try to evaluate if the TSSF PosSizer might work. After looking at how the win% rate jumps around, I'm wondering how well the TSSF PosSizer would perform? I can't remember if the TSSF PosSizer has an adjustable lookback period. And if it does, how it should be set for a buy-high strategy?

Thanks for fixing the visualizer. I'm gathering the win% rate will still bounce around with large datasets in a choppy market when employing a buy-strategy. Interesting behavior.

---
I have another question. Are we expecting the "fixed" win% visualizer to now chop to either 0% or 100% (and only those two values) when the lookback period is set very small? I'm assuming the answer is "yes".

QUOTE:
So the lookback period is in trade units and not bar units. I never knew that. You might add a "#of trades" label to that control.

The (partially crippled until maximized) title says exactly that: 'Rolling Performance Metrics (XX trades)', and it's highlighted in the online user guide where it repeatedly talks about 'a rolling XX-trade window'.

QUOTE:
I have another question. Are we expecting the "fixed" win% visualizer to now chop to either 0% or 100% (and only those two values) when the lookback period is set very small? I'm assuming the answer is "yes".

Well, with 2 trades as the lookback it can take only 0%, 50% or 100% values; with 3 trades - 0%, 33%, 66% and 100% etc.

@superticker

Fixed. Thanks for bringing it to my attention. Please update the extension.

The "Win Rate% plot" fix looks good to me. Just what I would have expected with Win Rate% oscillating between 0% and 100%. See the "performance metrics" attachment. Thanks a bunch for fixing it!

I think the Profit Factor plot might be correct. What's illustrated is a buy-high strategy, so when the market goes bullish, the Profit Factor goes crazy for a small lookback period. There simply needs to be a larger lookback period that includes some correction (bearish) days.

I realize WL isn't trying to produce publication-ready graphs, but it would be nice if both origins of the "Profit/bars held" plot fell on the same horizontal. I initially thought the line plot was going negative when I saw it. See "profit per bars held" attachment.

You're welcome.

QUOTE:
There simply needs to be a larger lookback period that includes some correction (bearish) days.

+1. To be statistically valid, a lookback of 30 or more is expected.

QUOTE:
I realize WL isn't trying to produce publication-ready graphs, but it would be nice if both origins of the "Profit/bars held" plot fell on the same horizontal.

Can a number of trades (on the right) be negative just as an average profit % figure (on the left)? That's the reason why these curves not always fall on the same horizontal. Your own screenshot is an ideal illustration of my point that AxisY is type double while AxisY2 is for natural numbers only.

QUOTE:
I was able to find Mikhail Korolyuk excellent article "Be In-Phase" about TSSF on the WayBack Machine here: https://web.archive.org/web/20140210034343/http://championship.mql4.com/2008/news/366

Thanks for sharing the link, Superticker. This TSSF business seems to show good potential. Of course, we are too far beyond a true bear market now so a full range of backtesting is not feasible.

Do any of the available WL visualizers show the 2 curves mentioned?


The "Rolling Performance Metrics" tab seems to plot the underlying data points, without plotting the actual curves. It would be helpful to see the 2 curves with perhaps a scatter plot of actual (rolling) trades, if that is feasible.

Also, this one with the actual TSSF values plotted (along with the one below it showing the corresponding drawdown trades) -

Notice from Mikhail Korolyuk's TSSF (Trading System Safety Factor) "Be In-Phase" article, the Avg(Win%)/Avg(Loss%) plot basically gives you the TSSF plot without the safety factor translating the vertical axis. So either plot is useful.

The Rolling Performance Metrics visualizer predates the Wealth-Lab TSSF PosSizer http://www2.wealth-lab.com/WL5Wiki/psTSSF.ashx. I think the "assumption" is that you would install and tune the TSSF PosSizer in WL so you would no longer need the Rolling Performance Metrics visualizer plots anymore. Have you tried that?

What WL PosSizers bring to the table is the ability to disenfranchise WL strategies (by shrinking their purchasing power) that no longer work with the current market climate (sentiment). For example, one would want to disenfranchise a buy-high strategy in a bear market and boost the same strategy in a bull market.

Personally, I have not used WL PosSizers to throttle the influence of individual WL strategies based on market climate. But if I were going to use them, the TSSF and Trading the Equity Curve http://www2.wealth-lab.com/WL5Wiki/psTradingEquity.ashx would be the two PosSizers I would try first.

@WLP123

+1 for trying out the TSSF PosSizer as @superticker suggests. What you're asking for is to build essentially a two-tabbed performance visualizer to "rephrase" the Rolling Performance Metrics (one tab for the curves+scatterplot and another for the TSSF).

QUOTE:
I think the "assumption" is that you would install and tune the TSSF PosSizer in WL so you would no longer need the Rolling Performance Metrics visualizer plots anymore. Have you tried that?

Yes, I have. That's what I meant when I said "it seems to show potential... "

Having the graphic visual for the TSSF curves would help understand how the backtested trades perform within this context. Might assist with "tuning" as well which to your point can be done with trial and error. While I'm a bit leery of configuration changes from default/standard values (if they are such), if we are "fitting the curve", we might as well use the actual curve :)

QUOTE:
What you're asking for is to build essentially a two-tabbed performance visualizer to "rephrase" the Rolling Performance Metrics (one tab for the curves+scatterplot and another for the TSSF).

Right, that would provide the visual as per the article referenced. If it's not worth the trouble, no worries.

QUOTE:
Having the graphic visual for the TSSF curves ... might assist with "tuning" .... ... if we are "fitting the curve", we might as well use the actual curve :)

I "think" you're hinting to rewrite the TSSF PosSizer so it fits a regression model that mirrors the TSSF curve.

I agree, a regression model that fits the TSSF curve would be "theoretically" better. But I'm not sure how accurately these fuzzy systems follow the theoretical TSSF behavior. In other words, whether the TSSF PosSizer uses a simple one-term linear regression model, or a multi-term regression model (precisely following the TSSF curve), I question whether the results would be much different. Typically, with fuzzy systems, a "close answer" is good enough.

But I now understand where you're coming from when you're wondering how the scatter plot of "actual data" would look on the theoretical Avg(Win%)/Avg(Loss%) vs. Win% plot.

----
If you're planing on publishing a paper comparing the residuals of the actual data verses the theoretical Avg(Win%)/Avg(Loss%) vs. Win% plot, you might consider passing this problem to R for analysis. The R.NET package https://systematicprogrammer.wordpress.com/2013/02/07/forecasting-statistical-analysis-of-time-series-models-using-c-and-r-net-with-r-engine/ lets you interface R with any .NET application such as Wealth-Lab. I haven't done this yet, but it's on my list of thing to do.

QUOTE:
I "think" you're hinting to rewrite the TSSF PosSizer so it fits a regression model that mirrors the TSSF curve

I'm only suggesting we be able to visualize the trades in the context of the actual TSSF values and the Safety/Zero Return curves, to gain a better understanding of strategy performance through market conditions. And then perhaps use this knowledge to manually configure the sizer parameters (although that's the part I'm leery about because of "fitting the curve").

However, to your point, if the sizer could somehow tune the parameters dynamically based on past performance, that would be a big step up, and bring us even closer to the "holy grail" strategy as hinted in the article. Especially in highly volatile market conditions, interspersed with periods of flatness (as has been the case this year), that find of fuzzy logic might be useful. But that level of AI on a position sizer is almost certainly not within the scope of WL, and not my expectation.

QUOTE:
I thought that is what that PosSizer was built for already? If not, what would be the logic/purpose...

Perhaps I misspoke. The TSSF values may already be linearized for us to scale thanks to Mikhail Korolyuk's workup.

What's nonlinear is the Avg(Win%)/Avg(Loss%) vs. Win% plot, not the TSSF values. I'm not sure what the error bars on the TSSF values would look like. Would the error bars have a uniform variance across all values of TSSF,... or would you need a weighted fit?

QUOTE:
if the sizer could somehow tune the parameters dynamically based on past performance

I'm trying to decide if you could even find a stable (reproducible) solution here? It's like you're trying do "nested tuning" for nested models (The strategy model is nested inside the PosSizer model.) Sound dangerous if the zeros/poles of the two nested models are too close on the root locus plot. Now we're making this a dynamic control system engineering problem.

QUOTE:
The strategy model is nested inside the PosSizer model.

Or they are complementary... a position size is required once the Strategy comes up with an entry. The Strategy comes up with an entry regardless. No position sizer tuning will/should affect that. Only rejected trades based on insufficient capital, of course, but that is an expected "side effect" with any sizer. All the sizer is trying to do is determine how "deep" to get in, based on market conditions (herein represented by the TSSF value in correlation with the curves) - a critical component of the trade.

QUOTE:
The strategy model is nested inside the PosSizer model.

QUOTE:
Is it though?

Yes, it is because you're tuning the parameters of the PosSizer from recent past performance, and that will depend on strategy parameters. So everything is interconnected and that means it could have an unstable solution.

Now if you can come up with a method of tuning the PosSizer that's not dependent on any strategy parameter settings, then we would be good for sure. The fundamental problem is both strategy parameters and PosSizer parameters are dependent on stock performance (gains). We would need to break that "both" factor to simplify this dynamic tuning problem.

----
In control engineering, we do work with such dependencies (via a root locus plot), that's not unusual. But we are controlling a well behaved, predicable, "physical" problem. However, in stock trading, we are dealing with a fuzzy system that's not well behaved at all. I'm not even sure one can solve for a dynamic nested-parameter fuzzy model reliably like we do with a physical model.

In Wealth-Lab, the only dynamic tuning is done with "adaptive" indicators. This is a WL limitation (and I've written my own adaptive thresholding routines to get around some of this), but there's also a reason for it. If both the WL indicators were adaptive and the strategy parameters were adaptive (dynamic), the WL simulation could become unstable if you're not careful because both have the goal of maximizing returns. Likewise with adaptive PosSizers if they are also trying to maximize returns.

QUOTE:
So everything is interconnected

True, but the rest of the strategy parameters are not being tuned by the position sizer itself. They are static values for the duration of the backtest (by design). Since the strategy itself does not have access to its own past performance (across symbols in a backtest), it makes such position sizers not only invaluable, but required, in order to properly size current positions with any level of confidence based on successful backtests using the sizer. If the strategy code could somehow do this internally, then I would agree with you that tuning both at the same time could result in instability.

QUOTE:
... but the rest of the strategy parameters are not being tuned by the position sizer itself.

That's true for the standard simulation (backtest). But what about when you're running the optimizer on the strategy parameters? Would you be disabling the adaptive capability of the PosSizer then? And even if you did, you could still have a see-sawing effect of parameter values with each optimization.

I would welcome more adaptive or dynamic parameter tuning in WL if it could be done with stability. I have had good success with dynamic thresholding of existing WL indicators to make their trigger points more adaptive. Some adaptation is a good thing in the right places. I agree.