Making a Python trading system for MT. - page 9
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
If you can write everything in MQL, you really don't need anything else.
I can't and I don't even want to write and go into details of algorithms that are already written, practiced and available. I don't want to use them directly, instead of rewriting or adapting to their application in MQL. By the way, this is the main concept of OOP.
Not to get into, OOP alone is not enough, we need component models of interprogram exchange and interaction, such as OLE->ActiveX->DCOM->.Net, otherwise we will always have to maneuver between languages and libraries.
I assume that Python, with its extensive libraries, won't need all of this for the foreseeable future. Except for terminal communication, but that issue has been solved long ago and even in several ways.
Honestly, this Python is annoying, along with its classes. Here's just a little snippet of one of the functions:
Count how many times the word self is repeated in this little piece of code ?
And all the time and everywhere, in every line several times. This nonsense will be repeated in all functions (methods) of any class all the time.
yep... Yes, python is good only as "glue", for scripting from a few to a couple dozens lines, then there's a clear advantage over C++\Java, but it's more expensive to implement multi-tier OOP in python, even at convenience level, the speed of such libraries is out of the question. Python is fun to show principles in presentations, etc. It is very "clean" in appearance from customization, which obviously need to be written in other languages, but to write something serious, with threads and GUI in Python is a real bummer
The own tester is more interesting because you can have complete control of the process, which is absolutely essential for testing. And the tester itself is a very simple construction.
I don't see the point of funding anything, as I do it only for myself.
I do it only for myself. The tester has not complicated algorithm, but there are a lot of places where I may make a mistake. But of course using someone else's developments can be no less risky, at least for the same reasons, and perhaps for some other reasons related to the specifics of "who benefits from it".
hum hum... Yes, python is good only as "glue", for scripting from a few to a couple of dozens lines, then there is a clear advantage over C++/Java, but it is expensive to make multilayer OOP in python, even at convenience level, the speed of such libraries is out of the question. Python is fun to show the principles in presentations, etc. It's very "clean" in appearance from customization, which clearly need to be written in other languages, but to write something serious, with threads and GUI in Python is a real grief.
Why "whew..."? Everything is fine there in Python, and the speed is fine too. Even the 55k loops work fine, in the penultimate-to-last versions. In fact, the libs in Python are fast, while Python itself is mostly for linking words in a sentence.
Generally speaking, talking fast - slow makes no sense in and of itself. If fast, what exactly is it for? If slow, then similarly.
What's with the "wheezy..."? Everything is fine there in Python, and with speed too. Even the 55k loops work fine, in the penultimate-to-last version. In fact, the libs in Python are fast, while Python itself is mostly for linking words in a sentence.
Generally speaking, talking fast - slow makes no sense in and of itself. If fast, what exactly is it for? If slow, similarly.
55k is crumbs, you need to count billions, and so the native python tester will not work, you will have to write and import the libu on the pluses, and python is only for calling and configuring, for it may be 100 times slower.
and "ahem" was about "self" and 100500 __***__ methods and attributes, IMHO they make much more complicated code than even on pluses, and if we talk about threads, events and GUI, everything is not any better than with pluses, rather the opposite, all this "duck typing" and stuff like that just starting to hurt, you need to keep a lot in mind, remember a lot of stuff55k is crumbs, you have to count billions, and therefore a native python tester will not work, you will have to write and import the library in plusses, and python only calls and configurations, because it may be 100 times slower.
and "ahem" was about "self" and 100500 __***__ methods, IMHO they make much more complicated code than even with pluses, and if we talk about threads, events and GUI, everything is no better than with pluses, rather the opposite, all this "duck typing" and stuff like that, on the contrary, just starts to hurt, you need to keep in mind a lot of thingsI don't know why I need billions)). The tester - I have no complaints, so far everything is fast, 3 months goes by in a moment, and I don't need more).
With everything else, I think I agree, on the pluses is more fun to write. But you can't really model on the pluses. It turns out: first we model somewhere in one software, and then we port it to the pluses, write all sorts of interfaces to the libs - it's a real hassle.
And in Python all in one package, and a normal simulation environment + all needed libs, usually in C++. For the strategy it is fast enough - 15-30 ms is not a delay for me. Eventually you can rewrite critical sections in C, as they do at NASA. If there will be any, of course.
And nothing is perfect at all).
I don't know why I need billions.)) Tester - I have no complaints, so far everything is fast, 3 months slips in a moment, and I do not need more).
With everything else, I think I agree, on the pluses is more fun to write. But you can't really model on the pluses. It turns out: first we model somewhere in one software, and then we port it to the pluses, write all sorts of interfaces to the libs - it's a real hassle.
And in Python all in one package, and a normal simulation environment + all needed libs, usually in C++. For the strategy it is fast enough - 15-30 ms is not a delay for me. Eventually you can rewrite critical sections in C, as they do at NASA. If there will be any, of course.
And nothing is perfect at all).
In the context of optimization it is billions when hundreds or even thousands of tests are run on hundreds of thousands of minute bars. We are not our enemies waiting for hours to fetch a couple of simple genetic indices for a year of minutes, it should be done in seconds, while in Python it will take much longer, just like in black boxes with deliberate slowdown of calculations.
And python in general is very attractive tool in right context, though IMHO its current popularity is a transient phenomenon, it is something like fashion on social networks and Apple gadgets, there is a connection with outer shine and minimalism on very simple examples, and also students which inflate its ratings.
PS By the way what makes you think your tester is working correctly? The tester is a tricky thing....
Billions in the context of optimization when the test is run hundreds or even thousands of times on hundreds of thousands of minute bars. We are not our enemies waiting for hours for a couple of simple genetic indices for a year of minutes, it should be done in seconds, but in Python it will take much longer, as well as on black boxes with deliberate slowing of calculations.
I'm not in the business of optimization and all sorts of parameter matching. My methodology is different, but I need an environment similar to MatLab, R, SciLab, etc. Python is just as good.
I also don't need 10^6 bars. For everything - about 6, maximum 9 months on minutes is enough. Now the test is 3 months -2.5 m, though the system is not so complicated yet.
The longest one is learning ML, but there is nothing better than Python, and here it is only as a scripting language. Let's say the response of a trained neural network of 5 layers, about 60 neurons is 3-5 ms.
So far, I don't see any real proof of the scaremongering.