Backtester-s-Equity-collection-appears-stuck-in-a-custom-ScoreCard

QUOTE:
Apparently, the Equity collection for the backtester freezes to a fixed value at some point even though trading on the instrument continues. What's really weird is this value freezing only occurs in the ScoreCard plug-in (called ScreenCard.cs below).

But it does not with the production ScoreCards which implement the same interface correctly, right?

QUOTE:
But it does not with the production ScoreCards ...

Honestly, I don't know. What I can tell you is the Debugger breakpoint is set on the first executable statement of Initialize(...), so the Equity collection is messed up right at that point.

I can also tell you that the functionality of the other methods in the ScreenCard were tested successfully.

I also tried running it with a couple different Sample Strategies, and it had the same problem.

So what's causing this behavior? And why is only the tail end of the Equity collection affected? It's almost like one parameter on the "parameter stack" is overrunning another parameter's stack memory. Isn't "managed code" suppose to prevent that if the compiler knows the correct length of all the parameters passed?

I can email you the code if you like.

QUOTE:
What I can tell you is the Debugger breakpoint is set on the first executable statement of Initialize(...), so the Equity collection is messed up right at that point.

It doesn't happen to me in a single-symbol run on URA when setting a BP at Initialize() of BasicScorecard/ExtendedScorecard. There may be something about your workflow or Strategy settings affecting this that we need to get to know before moving forward.

It could also been a glitch in the VS debugger, I’ve seen things like that happen.

QUOTE:
It could also been a glitch in the VS debugger,...

I thought about that. But that brings us to the question, "Why was I looking at the ScreenCard behavior with the debugger in the first place?" And that's a complicated question.

So the ScreenCard.cs throws an unhandled exception because the Math.NET regression routines can't find a regression solution for the equity curve, which would be expected if the equity curve wasn't moving with the trading. It gets weirder. The regression setup is in another assembly, Superticker.Components, as a static method in a static WLUtility class used for all static methods including extension methods. The VS v17.3 compiler griped (warning) about this configuration not working with my version of Windows 10--what on earth? I kind of had the impression the OS wasn't able to dynamically load the other assembly, but I'm guessing and I don't know why this version of the OS would fall short of this task; I got the latest Win10 Pro patches.

I decided to upgrade VS to v17.7.6, and this warning went away, but now I get the unhandled exception from the static method in the WLUtility class of the other assembly.

I think to give the original v17.3 compiler the benefit of the doubt, I'm going to move the static method into the ScreenCard class as a private method and see what happens. The static method (in the other assembly) works great in Cleanup and makes beautiful plots of the equity curve activity. And I've been using it for months.

I'm not seeing any issue debugging the ScoreCard equity curve in our ScoreCards. All values are returned as expected. This must be Visual Studio related, a problem with the debugger. There's nothing we can do to solve this for you.

Have you tried to run the ScreenCard code I sent you? It crashes. Why is that?

The debugger says the Y values (equity values) stop changing even though the X values continue to change. If that's not happening, then why are the numerical routines crashing? Something is going on.

I don't care if the debugger is working or not. I just want my ScreenCard code to work. Let's concentrating on fixing that, not the debugger.

I wasn’t able to compile it because one of the required assemblies wasn’t included.

@superticker, you may have already checked for this, but if not, check your code to see it is swallowing exception(s). You know...

CODE:
try
{
    // do whatever
}
catch
{
   // ut-oh! not thrown, no logging, etc.
}

OK I was able to get your ScreenCard compiled, by just removing the offending reference to Superticker.Components since it wasn't actually needed. I'm not having the same issue; I'm getting all of the equity curve values when I launch your ScoreCard project attached to WL exe.

QUOTE:
The ScoreCard is now returning results.

That's great news. Send me the bill for the amount I promised. (I burned days trying to troubleshoot these problems, so the payment is well worth it!) I only ask that you improve the ScoreCard documentation (which is incomplete) and show examples of setting Short results and Buy & Hold results.

I reread the existing documentation, and I have no idea how to set the Short results or the Buy & Hold results--there's no mention of them. I didn't even know setting these was required (let alone how to set them).

Email me the code. I want to see how you fixed it.

Will do. In short, your ScoreCard Initialize is called FOUR times. Once for the combined results, once for long only, once for short only, and once for the benchmark. You don’t need to do anything special other than ensue your ScoreCard can process different results, including results with zero positions.

QUOTE:
... your ScoreCard Initialize is called FOUR times. Once for ...

I didn't know that. Is that documented anywhere? How does Initialize know which of the four cases (combined, long, short, benchmark) is being processed at the time? Or are you saying only one case of "positions" is presented at each time by the backtester to Initialize?

Is it important to exclude NSF positions? That's not discussed in the docs either.

If you posted some example code, that would be a big help.

Your ScoreCard should simply process the incoming information. It doesn’t need to know which case is being sent.

NSF positions needn’t be considered.

To summarize, we think everything you need is already documented. Your ScoreCard had a bug and after I fixed it, it’s working well.

QUOTE:
we think everything you need is already documented.

You should definitely discuss the zero positions case and include that as part of the examples in the docs.

I wouldn't over documented it, but some mention of NSF position considerations would be worthwhile. I was concerned that NSF positions may have a zero profit argument, and therefore could crash the polynomial fit.

The numerical analysis (polynomial fitting) part requires at least three positions to uniquely determine the 3rd-degree polynomial (i.e. 3-term polynomial). So if there aren't three valid positions, it will need to be bypassed.

Thanks for the clarifications.

Not trusting the VS Debugger, I decided to use StreamWriter to dump the EquityCurve to disk to see what's there. The good news is that it's all there. The bad news is that the bar numbers in the EquityCurve are out of time synchronization with the bar numbers in the Positions collection. The latter starts bar=0 at the beginning of the Data Range; whereas; the former starts bar=0 where StartIndex thinks trading should start.

That's all fine and dandy, but what's the most reliable way to determine the bar# "offset" value between Position variables and EquityCurve variables? I would like to use bar# to address them since this is the fastest way (because they are indexed by bar#, not DateTime), but I need their DateTimes to match up for the polynomial regression analysis.

If you have a simple code example to compute the bar# offset between the EquityCurve and the Positions variable, please include it. I'm assuming this offset will remain constant for the duration of the ScoreCard procedure.

---
Off topic, but there isn't a time synchronization problem between the EquityCurve and the Positions collection inside the Cleanup{...} block. Their bar#'s automatically align.