Well, no. You yourself wrote in your 2M lines backtest article that for a complete backtest, order objects are created -- these take CPU cycles and memory. So it's not exactly separate is it. The approach you have with Backtrader is relatively straightforward to implement, with pypy and great implementation it might be as fast as vectorization, I'll use BT as a benchmark. My goal is to have something that's cheap on resources and large data, not something that is extremely versatile and implements all strategies. My (relatively simple) trading logic doesn't take more than a few seconds to apply on half a million lines or so, that's fine for me. I'm quite sure it takes longer with anything that loops. That's all great but off the shelf frameworks don't do it for some of us. It's sort of like telling a racing driver "don't worry about what car it is, just drive it". We all know the car matters and will impact end results. Having a data, backtesting and automation tool that you built means you can implement a strategy fast, know the details of the operation, can fix bugs immediately and implement new features within minutes. No retail software allows for this. I've seen bugs pop up in the morning and I've patched it before market open. If I didn't know how or didn't have access to code, I'd be in some forum pleading a developer to do it for me...
I guess you will probably implement the tam-tam air gapped protocol to pass messages from the trading logic to the execution engine (aka ... broker) or you may even write down with pencil and paper what the logic provides and then pass it then to the execution engine. Don't you think that the order objects are the messages being conveyed back and forth? It may seem it shows ... separation. Incredibly ... that's what allows people to integrate with other data sources/broker providers without having to touch the core of *backtrader* or having to alter a single line of the trading logic. Yes, straightforward. Supporting `Market`, `Limit`, `Stop`, `StopTrail`, `StopLimit`, `StopTrailLimit`, `MOC`, `Bracket`, `OCO`, cross-asset compensation orders, real-time futures cash adjustment, leverage, volume based filling, time constraints, ... it is all straightforward. When you have implemented all that in your ideal (bingo bullshit word) vectorization environment, let me know how straightforward it is. So even if you said you were not, by your own admission you are concentrating on implementing something which is single case oriented, yet you feel to criticize what has a wider, more generic and a lot more useful goal. What will it happen when your "simple" trading logic is no longer so simple? Won't you ever implement anything which uses something like a `Limit` order?
Yeah, you're definitely German. The point is that backtesting doesn't have to be tied to live trading, it could and probably should be separate. You're making it sound more complex than it is. I'm not suggesting everything is trivial but take MOC for example, what's complicated about it? It's an on-close order that has to be submitted before 15:45 or 15:50 for most types of orders, what's highly complex here? I won't be implementing everything you have in any case as I have no need for it.
I cant' imagine what that foolish (and completely wrong) assertion may even try to imply. Oh yes I know ... "I said so many things which have been proven wrong that ... I have now to resort to go personal" Write two systems instead of one. Vectorization as its highest. The arguments from previous comments suggested that one could do everything with the bullshit bingo word *vectorization* and that looping is for old ladies only. And one has now to write two separate systems. Call Netflix and let them know that Orange is not the new black. You said that *backtrader* does something straightforward and I listed only one of the things it does ... which is supporting many different order execution types. Some of the things are obviously more straightforward than others, the point being that supporting those (and many other features) to have something open for writing generic strategies isn't straightforward. Now your pick is to go for what you think is simple and serves you as ... "hey ... it ain't that complex". Why don't you pick Bracket orders? Or OCO? Or StopTrailLimit with percentage based trailing amounts? In any case and with the bingo bullshit buzzword *vectorization* being considered, let me please know how you support *MOC* being issued during ANY (not a fixed bar) intraday bar and be executed with the evaluation of the last bar? (Let us remember that exchanges have the bad habit of not always closing at the same time) Let me state it again: there is nothing against the development of a vectorized system which supports a specific pattern. But you are there to freely criticize what you consider *slow*, *straightforward* and ... when the vectorized system can by no means support what that stupid straightforward system can.
It's not personal but I noticed an abrasive style I've seen with some other folks from München before. But fair enough, I'm sure many find BT to be extremely useful and the more free software there is, the better.
Backtesters don't provide a facility for constructing situational awareness. Otherwise, you'd never need to comb through so much data to find something that works.
Like, what you mean, is that backtesting produces results, but even those results are random because a backtest is only looking at a thin slice of circumstances, the other big fat slice is impossible to implement due to a) the amount of additional data required, b) the additional data is unobtainable? If that's what you mean, I agree.
If it was all random then no-one could make returns over long periods of time. It's not really a discussion about whether backtesting works but rather the methods of backtesting.
Not saying all backtesting is random but largely random. It's largely random because 'Backtesters don't provide a facility for constructing situational awareness' as SteveH mentioned. The small amount which is not random is why a good trading system will be lucky with 50% win rate.