The arrival of a new generation of trading software. What should the EA interface be like? - page 13
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
I think we should start with the expert. I have given three types of tasks that are relevant to the expert, but it turns out they are not feasible in your interface.
What could help? Perhaps deeper integration, or limiting the project to "remote control".
your energy into peaceful purposes :-)
Of course, I understand that development of GUI libraries is a creative and in some ways even rewarding business (you write code, draw windows, see the result). But it's such a dead-end and so much wasted time...
In short, how do you hook an alternative GUI to MT:
- A DLL is written that:
- at first call creates a separate trace and initializes graph subsystem
- for each user two message queues - from MT to GUI and vice versa.
- an MQ4/5 class is created that basically processes/filters messages in these queues and moves them back and forth from the СhartEvent
- an optional API for sharing structures and synchronizing arrays
this way you can hook into virtually any modern system:
- you can use Dotnet with its winforms and otherShare (there was an article somewhere on the resource on how to hook manager code and make dlls in C#)
- gtk and design in glade https://glade.gnome.org/
- Qt with its designer https://www.qt.io/ui/
- you can even run a http server with some restrictions :-)
The "right" architecture turns out to be - the explorable GUI lives in a separate thread and doesn't slow down EAs/indicators. The GUI is designed and drawn by "specially trained people" :-) Expert Advisor/indicator is practically a "model" (like in MVC and similar).
I didn't say that these tasks are not feasible in my interface). I meant that the technologies based on OOP can not be integrated into my code, due to incompatibility of approaches. I'll have to implement these tasks myself, after I've finished implementing the basic (highest priority) things.
OOP has nothing to do with it. Of course, you can pass strings and events through global variables, but this is a special case, but not for a large-scale project, moreover, claiming to be "a new generation of trading programs".
your energy for peaceful purposes :-)
My aims are purely peaceful).
Your suggestion is interesting. I suggest you try to implement it.
Personally, it is quite obvious to me: preferring other people's solutions to your own is a choice against yourself.
MT has its own language. Why do you need it when you have C++ and C#? Why was it created?
I think it was created because those languages weren't optimally tuned for algotraders' tasks. They needed a specialized, applied language.
Users don't care how to create an interface, as long as it can be done easily. Create an interface, as you suggest, can only be created by a serious pro, while for the others it is sometimes difficult to use the standard MT library, not to mention the different connections of third-party programs through DLL.
If I was developing your version, I would not be able to disseminate it in the community, where as you know DLL can be used mainly for myself. And what good would this solution do to others?
Your solution is possible, but it cannot be widely distributed.
OOP has nothing to do with it. Of course, you can pass strings and events through global variables, but this is a special case, but not for a large-scale project, moreover, claiming to be "a new generation of trading programs".
Friends, I'm getting back to work on a project that has stalled a bit while I'm busy chatting on the forum. I will periodically post here about the progress of my development and reply to everyone.
If you have any thoughts, ideas or suggestions for the interface of future EAs, feel free to write.
Thank you.
However, such difficulties as the lack of technology, the absence of common standards, low quality of created graphics and other problems faced by programmers who took the risk of creating a user interface of their trading robot. It became clear that it is much more difficult to create a complete UI for MTs, than to code the trading logic, write algorithms of gathering statistics or implement pattern recognition into a strategy. It is these difficulties that became an obstacle for the transition of algorithmic trading to a new level of algorithmic trading, where the area of necessary human-program interaction is greatly expanded, increasing the effectiveness of trading and unlocking the potential of the most original ideas. The area of interaction, which allows to compensate for program disadvantages of "iron" binding to algorithms, by the flexibility of human thinking.
Now EAs are like trams that run strictly on rails, and users do not know about others, but imagine if EAs become like cars, with the option to steer in any direction? With such "cars" you can feel much more confident in the market...
Good afternoon everyone.
Very well written about the new level of algorithmic trading. The fact - a modern interface for trading is a very necessary thing. How to create it is a separate question. We, for example, have live statistics on our site. But it is possible if the robot is tied to an external resource and the UI is implemented there. We have not tried to use infographics on MT and have created it where it is convenient. Moreover, an ordinary trader knows how to use a browser, and any new interface you still need to learn and get used to. For users individual statistics is on the way, a lot more is coming soon.
But about the tram: where do you steer? What do you mean? Our experience has shown that written, tested, and tuned robots that traverse the currency market "like trams" are safer and more effective than when traders steer. Going back to the tram - understanding which route it takes is important. But if the end point is the same - what's the point of a car? The probability of an accident is many times greater. It is precisely those who try to "steer" that cause us problems.
That's great! I would like that too. However, artificial intelligence could get greedy and take a percentage of profit in its pocket, or bankrupt the owner on the grounds of personal animosity.))
Good afternoon everyone.
Very well written about the new level of algorithmic trading. The fact is that a modern interface for trading is a very necessary thing. How to create one is a separate question. We, for example, have live statistics on our site. But it is possible if the robot is tied to an external resource and the UI is implemented there. We have not tried to use infographics on MT and have created it where it is convenient. Moreover, an ordinary trader knows how to use a browser, and any new interface you still need to learn and get used to. For users individual statistics is on the way, a lot more is coming soon.
But about the tram: where do you steer? What do you mean? Our experience has shown that written, tested, and tuned robots that traverse the currency market "like trams" are safer and more effective than when traders steer. Going back to the tram - understanding which route it takes is important. But if the end point is the same - what's the point of a car? The probability of an accident is many times greater. It is precisely those who try to "steer" that cause us problems.
Afternoon.
The essence of my concept of advisors of the future (working for MT), is based on the conviction that it is necessary to connect and centralize everything necessary, inside one program.
I am convinced that the maximum efficiency of any program lies precisely in its centralization and versatility. Combining the maximum number of relevant features and cutting off everything unnecessary, can qualitatively improve the efficiency of any mechanism, including the EA. At the moment, most of the proposed variants of trading robots are focused on attempts to connect incompatible languages and resources in different ways. They suggest using external DLLs, interfaces built in visual studios, different statistical services, etc... I should note that the task of increasing the capacity of the trading robot can be solved in this way, but it is obvious - this solution is inconvenient and not suitable for everyone.
Until every person, even a not very skillful algotrader, will not be able to independently (or with someone else's help) without large expenses to build a trading robot that he wants to use, and until he is no longer forced to turn to external resources trying to solve the most complicated tasks of integrating and fixing them, the trading robots will not leap to a new level. That is my belief.
External statistics and statistics inside a robot are fundamentally different things. In the first case only the user can monitor statistics and reset some parameters of his/her strategy, in the second case trading statistics can be analyzed by the Expert Advisor in real time, allowing the robot itself to adjust its settings. You can write algorithms for correcting trading strategy settings, with the option of complete replacement of the strategy at low statistical values. The development potential of this idea is obvious. This is what I meant by "steering", which is available to a car and not available to a tram.
An option where the EA is located on one platform, its interface is on another one, and statistics is on a third one, does not look good in terms of an ideal mechanism that everyone wants to have for his EA. ))
All it takes is a big "get paid" button on the screen, and the greens come right out of the DVD )).