Back

[charting] omit full charting data from finalResult to make messaging leaner

Charting is limited by quite a few constraints; it's perfectrly undertstandable why they're set if we consider the architecture they're built for.

Some of the major ones are limitations set on the max number of datapoints per series and number of series per backtest.
These limitations become less needed if we were to flush all the accumulated charting updates over ZMQ prior to algo termination, and omit charting data from the final {Backtest,Live}ResultPacket. Idea would be to make the charting data state handling the responsibility of the ZMQ consumer - that way the full charting history in the final message becomes redundant as it's already been consumed downstream.

Currently the high level charting data propagation is as follows:

1) algo calls QCAlgorithm.Plotting.Plot() family methods, private _charts contains all data;
2) from AlgorithmManager.Run, results.ProcessSynchronousEvents() is invoked;
3) from there SampleRange(Algorithm.GetChartUpdates()); is invoked
4) note charting data delta is pulled via QCAlgorithm.Plotting.GetChartUpdates
5) pulled delta updates are also stored internally in ResultHandler.Charts

Now everything's fine until ResultHandler.SendFinalResult() is invoked; the accumulated internal Charts is sent with the final {Backtest,Live}Result message, containing considerable amount of data if abovementioned limitations were relaxed.

I suppose the charting data in private Charts field should still be kept around as it's required for the final StatisticsResults calculation, but it appears wiping all the charts from the finalResult message shouldn't have any adverse effects. Is this reasoning valid?

Thinking something in the following lines:
a) make sure all charting data is flushed to zmq before final result is generated - how to accomplish this? Currently finalResult's charts always contain some charting data that weren't received prior; I assumed line results.ProcessSynchronousEvents(forceProcess: true); in AlgorithmManager takes care of it, but doesn't appear to be the case;
b) bump up maximum-data-points-per-chart-series config value;
c)
make max number of series per algo configurable;
d) omit charts from final result message (dependent on a))

Update Backtest







0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Solid idea Laur, thank you for the feedback. We have plans to review detailed charting later in Q1 or Q2 and will keep this in mind.

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


In order to work around this in the meantime with homebrew charting solution, could you confirm if a) above is a bug as it stands - ie. not all charting datapoints are sent prior to final {Backtest,Live}ResultPacket?
Whenever we count the datapoints for given Series, the total number received before the final message is always lower than number of datapoints for the same Series in the last packet; looking at the code I'd expect them to be equal.

Is there a github issue to monitor charting work?

0

>ie. not all charting data points are sent prior to final {Backtest,Live}ResultPacket?
This should not be the case but if you have a simple test to prove it we can look into it.

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Not easy to demonstrate without a consumer. Would you accept a diff for Engine/Results/BacktestingResultHandler.cs that shows the discrepancy?

Fyi the problem is caused by this check in BRHandler.Update():

if (DateTime.UtcNow <= _nextUpdate || _daysProcessed < _daysProcessedFrontier) return;

If either of these comparison checks are left in place, then some of the last chart datapoints will only be sent with the final message.

0

Update Backtest





0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Loading...

This discussion is closed