it simply means that your system should make a new global high before you are entitled for a payment. If your system makes 1000 at the end of January, 800 at the end of Februray, 900 at the end of March and 1100 at the end of April, your profit will be generated at the end of April and they will amount to 1100-100=100;
no, once the system starts being traded, it will be traded in the form it was at submission time, i.e. the quant will not be allowed to update parameters/change details. Of course a submitted system can have an adaptive logic, by changing parameters according to the value of some meta-indicator. If the quant believes there is some big change to be made, it is ok to re-submit the changed system, but it will need again to accumulate a track record before being traded.
@antinomy In the end we followed your advise and changed a little bit the algorithm for adding data, once a cryptocurrency is in the top10 we include it with its past history and go on with the update (now DASH and XMR are being updated). Of course once the crypto is not among the top 10, the liquidity tag for the filter is "zero". Thank you!
Ok, so looks like for now for all strategies without a state I have to output and pass None to weights for the state & pass a state variable to the strategy.
Will keep you updated. Thanks for looking into the issue.
Just out of curiousity I did some testing and it looks like the class actually was the culprit.
I submitted a simple strategy in 2 versions, one with a class and the other with a dictionary as state. The class version was rejected (exaclty like the one from my 1st post) and the dictionary version got accepted.
@magenta-grimer Hi, the lookback period in the backtester function is expressed in calendar days, and the indicators are expressed in trading days. So as far as the lookback period is long enough to include all indicator needed periods, all choices are fine.
If the longest period needed for an indicator is 10 trading days (2 weeks), a lookback period of (for example) 20, 50 or 100 for the backtester function will deliver the same results. The shorter the better for efficiency.
We are making some changes before starting competitions, it affected the statuses of some submissions and they became invisible on the client side. Now it should be ok.
We carefully preserve users' data, we are making backups every day. So in the worst case of data loss, we are able to restore most data from these backups. Don't worry a lot. And thank you for the report.
@magenta-grimer That is correct, but you can for example train a model locally on your machine, and then submit a code which uses the results of the training (for example stored in numerical form) but does not reveal the underlying idea.
The BTC spot we are using are daily data, and open/close/high/low are computed by matching the opening and closing time of the BTC Futures contracts. As we are working with daily resolution, we believe the spot BTC is ok for the current contest. Having the weekend data at disposal, signals can be built by using more information. Moreover, the previous time series were built matching the past spot data with the short futures data.
This change is not disruptive, as old algorithms developed on the BTC Futures will still run on the BTC Futures. You pointed in another thread the change in the leaderboard: many thanks, please allow us to check and fix it.
Most of the quants requested this change, so we went for it. Maybe in the future we will allow for both options, but please note that the BTC Futures have a short history, so they will have anyhow to be patched with spot data. Thanks for the suggestion.