It's a bigger account. The size is right. But the total orders placed is wrong
Index futures automation
- Thread starter hilmy83
- Start date
Perhaps it's time to spend some of the $8k (or whatever it came to) of the algo's unexpected bug-induced windfalls towards some professional software development, whether it be in QT, MT5 or another platform like NT.
That's a poetically great idea. The bug got you an unexpected win. Use that unexpected money to prevent anymore unexpactations <----(I just invented that word.)
You have an incomplete system.
Perhaps you got a bit over anxious to trade after the back test alluded to profits.
Incomplete is incomplete, regardless of PL behavior. The path that is happening is the same as a manual trader going off half baked because they see profit potential and just starts trading.
No ChatGPT, band-aid fixes or even surgical fixes will make the system complete. This is why you write your own code. So you know when the code is collapsing under its own weight and needs a new architecture. Problem is you cannot accurately make this assessment because you did not write the code or cannot code review it enough to add the incomplete parts
Ultimately, only highly experience software and or traders with algo experience should have others write code. You simply did not spec out the code sufficient enough.
Fun fact, 70% of the code in MS word is error handling. How much of this trading code is error handling?
Same mistake as manual trading. Chasing $$$ instead of fundamentals.
Sorry to be a downer, but just trying to keep it real.
BTW: since June, I have been running an ES algo. Trades from open +2.5 hours. Single contract, single position. Up 3.5K on 20K start. PL and risk aside, only one error in order handing, which was minor and fixed. Hit over a dozen "error" conditions and handled all but the one mentioned above. The code was to test the waters of live trading, and not lose money. Now I can start-continue work on the "Make money" - "risk adjusted" version.
Perhaps you got a bit over anxious to trade after the back test alluded to profits.
Incomplete is incomplete, regardless of PL behavior. The path that is happening is the same as a manual trader going off half baked because they see profit potential and just starts trading.
No ChatGPT, band-aid fixes or even surgical fixes will make the system complete. This is why you write your own code. So you know when the code is collapsing under its own weight and needs a new architecture. Problem is you cannot accurately make this assessment because you did not write the code or cannot code review it enough to add the incomplete parts
Ultimately, only highly experience software and or traders with algo experience should have others write code. You simply did not spec out the code sufficient enough.
Fun fact, 70% of the code in MS word is error handling. How much of this trading code is error handling?
Same mistake as manual trading. Chasing $$$ instead of fundamentals.
Sorry to be a downer, but just trying to keep it real.
BTW: since June, I have been running an ES algo. Trades from open +2.5 hours. Single contract, single position. Up 3.5K on 20K start. PL and risk aside, only one error in order handing, which was minor and fixed. Hit over a dozen "error" conditions and handled all but the one mentioned above. The code was to test the waters of live trading, and not lose money. Now I can start-continue work on the "Make money" - "risk adjusted" version.
Last edited:
Which platform you're using to automate?
Multicharts. I am using the scripting language for prototyping. Once I have something to go into production, I will recode in C, maybe.
The thing is, a lot of system decisions can vastly change how stable and reliable your system runs. These decisions are more important than most understand. Consider restarting your efforts. You can always run this one later, but right now it is taking up all (most?) of your trading efforts.
Also note, MC has a bunch of order handling crutches that you do not have to rewrite. Are they bullet proof? Probably more like bullet resistant, and do function reasonably well.
You got a system operational, although the catastrophic drawdown, is a non starter for most people. Scripting the existing system, and then figuring out how to eliminate the intra trade drawdown is then possible with a prototyping tool because it is fast and easy to test against the market data.
No trades tomorrow.
I'm trying to compile all the issues I've seen over the last several months and things that I can think of, to add to the strategy writeup to basically include the error handling process.
Things like delayed order placement, VPS disconnection, naked positions, naked orders etc.
Error handling in algorithm creation refers to the process of identifying, managing, and responding to errors or exceptions that can occur during the execution of an algorithm or computer program. Errors can arise for various reasons, including incorrect input data, unexpected conditions, hardware failures, or programming mistakes. Effective error handling is essential to ensure that the algorithm or program operates reliably and gracefully, even when problems occur.
Here are some key aspects of error handling in algorithm creation:
I'm trying to compile all the issues I've seen over the last several months and things that I can think of, to add to the strategy writeup to basically include the error handling process.
Things like delayed order placement, VPS disconnection, naked positions, naked orders etc.
Error handling in algorithm creation refers to the process of identifying, managing, and responding to errors or exceptions that can occur during the execution of an algorithm or computer program. Errors can arise for various reasons, including incorrect input data, unexpected conditions, hardware failures, or programming mistakes. Effective error handling is essential to ensure that the algorithm or program operates reliably and gracefully, even when problems occur.
Here are some key aspects of error handling in algorithm creation:
- Error Detection: The first step in error handling is detecting when an error or exceptional condition occurs. This may involve checking input data for validity, monitoring for unexpected behavior, or using specific error codes or flags.
- Error Reporting: Once an error is detected, it's important to report it in a clear and informative way. This can include displaying error messages, logging the error details, and potentially notifying users or system administrators.
- Exception Handling: In many programming languages, exception handling mechanisms are used to deal with errors. Exceptions allow the program to gracefully handle unexpected issues by providing a structured way to catch and respond to them. Common exception handling constructs include try-catch blocks.
- Graceful Degradation: In some cases, it's important for an algorithm or program to continue functioning to some extent even in the presence of errors. Graceful degradation involves designing the algorithm in such a way that it can still provide meaningful output or partial results even when errors occur.
- Logging and Debugging: Robust error handling often involves detailed logging of errors, which can be useful for debugging and diagnosing issues. Log files can be valuable for troubleshooting problems in a production environment.
- Error Recovery: Depending on the nature of the error, some algorithms or programs may attempt to recover from errors and continue execution. This could involve retrying a failed operation, switching to an alternative method, or applying corrective actions.
- User-Friendly Messages: When errors occur, it's important to provide user-friendly error messages that explain the problem in a way that non-technical users can understand. Clear error messages can help users take appropriate actions or seek assistance.
- Testing and Validation: Rigorous testing and validation of the algorithm can help uncover potential errors and ensure that the error-handling mechanisms are effective. This includes testing with different input data, edge cases, and scenarios that might trigger errors.
- Security Considerations: Error handling should also take into account security concerns, such as preventing information leakage through error messages (i.e., not disclosing sensitive information) and defending against error-based vulnerabilities like SQL injection.
- Documentation: Documenting the error handling strategy and providing instructions for handling errors can be beneficial for developers, maintainers, and users of the algorithm or program.