Logging something on the last day of backtest

Back to Community

posted

    # Log something on FIRST minute of last day, once  
    if get_datetime().date() == get_environment('end').date():  
        if 'summary_done' not in context:  
            context.summary_done = 0  
        if context.summary_done:  
            return  
        log.info('Some summary information, first minute of last day')  
        context.summary_done = 1


    # Log something on LAST minute of last day  
    mode = get_environment('data_frequency')  
    if mode == 'daily':  
        if get_datetime().date() == get_environment('end').date():  
            log.info('Last frame, daily')  
    elif mode == 'minute':  
        if get_datetime() == get_environment('end'):  
            log.info('Last frame, minute')

Anyone know of an easier way? This is a lot to do to get there.

6 responses

André Pajak

There should be a user-definable function, perhaps called finalize, corresponding to initialize, called automatically by Quantopian after the end of each backtest. Q: consider this a feature request. Should be easy to implement.

Jamie McCorriston

Thanks for the request guys, I've passed it along to our engineers!

Disclaimer

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 Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian 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.

André Pajak

Thanks, Jamie.

In addition, I have the following feature requests:

Complementary to before_trading_start, there should be after_trading_end, called after the end of each trading day.
There should be similar pairs of functions, one called before the beginning, the other after the end, of each week, month, quarter, and year. They should be called in the proper order: those corresponding to longer periods should be called before the before_* and after the after_* functions corresponding to shorter ones: initialize, before_year_start, before_quarter_start, ..., before_trading_start, handle_data, after_trading_end, ..., after_year_end, finalize. That way, monthly summaries can be used to build quarterly ones, quarterly for annual, etc.
Meta-request: There should be symmetry. For example, there should be a getter for every setter, eg. get_universe corresponding to set_universe, as well as get_commission and get_slippage; see my posts from earlier this year.

André Pajak

Another feature (or bug removal) request: allow schedule_function with minutes=0. That would make it much easier for us to write our own periodic initializer and finalizer functions as described above, as well as cancelling open orders at the end of the day if we so choose.

Jamie McCorriston

André,

Because of the way that data is loaded using the concept of the universe, having an after_trading_end would not exactly be symmetrical to before_trading_start. Unless I'm missing something, it seems this functionality can be achieved with schedule_function() (as I believe is the same for the other requests in #2). The before_trading_start function is special since it doesn't have a universe defined yet. Would this be something you would want in the other functions you suggested? Regarding #3, do you think you could give me an example of where get_commission and get_slippage would be helpful? Given that they're constants, it's not immediately obvious to me. Of course, I'm sure I'm just not thinking of certain use cases, so any examples you can give would be helpful :)

Thanks

Disclaimer

André Pajak

I'm not too concerned yet with setting and changing the universe. As I understand, the universe is set before initialize using results of a preprocessor run looking for calls (or what appear to be calls) to sid, symbol, or symbols (and it seems you can't use both sids and symbols in the same code). It can then be changed by no more than one explicit call to set_universe in initialize and/or any number of calls to update_universe in before_trading_start. Thus, when before_trading_start is called, a universe is already set. Correct?

My present need for a function like after_trading_end is for simple bookkeeping: say, how many shares of which asset I bought, how many sold, at what average price, what my gross and net profit or loss was, and how much I paid in commissions. I want that calculated and displayed after trading - not during trading, when orders might still be sent after the summary (even at 4:00pm), and not before the start of the next trading day, because I shouldn't have to wait till Monday morning to see how I did this week, and because this may be the last day of the run and the next before-trading-start will never happen. I think the code to call after_trading_end would be simple and similar enough to the code that calls before_trading_start, and so wouldn't cost Quantopian much; but it would make algorithm writers' work much easier. Convinced, unconvinced?

At present, I use my own after_trading_end, set with schedule_function to run 1 minute before markets close (because minutes=0 causes a runtime error, even though there's no good reason), and a Boolean context.trading switch set in before_trading_start and cleared in after_trading_end, which seems to run after handle_data at 3:59pm. Very inelegant.

Other before_*/after_* functions can wait. With after_trading_end and/or minutes=0, they shouldn't be too hard for users to write.

I do need get_commission to calculate how many shares I can afford to buy or have to sell, and because I like to know what I'm paying. I could keep commission parameters in context and pass them to set_commission, but Quantopian won't allow it in the contest, even in a comment. I want my algos to meet all the contest requirements as well as to calculate numbers of shares correctly, even if Quantopian later changes its default commission scheme. This is currently impossible.

Others might need get_universe to see why they can't sell what they bought before a call to update_universe. I only mentioned get_slippage because there should be a getter for every setter.

You've successfully submitted a support ticket.

Our support team will be in touch soon.