My approach. The core is the engine. - page 38
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
Well, well... Go for it, Peter.
You're right about 'degradation', but I think you're presumptuous about 'pulling users'.
But, go ahead. There may be someone out there who can program, but trades "hands off".
I'm thinking, there is a famous American platform for manual trading. It has the possibility to partially automate actions inside the platform, but you have to know how to do it. There is also an API. But how many will manage it?
We can write handy semi-automatics and offer them to clients. And not only them. All traders who trade manually may be offered partial automation of actions, monitor the market from tables and interact with the program using dialog windows. Display messages on market events. Well, maybe I don't know or understand something, but in theory?
We, on the other hand, can write handy semi-automatics and offer them to customers. And not only them. We can offer all traders who trade manually partial automation of their actions, observe the Market from tables and interact with the program through dialog windows. Display messages on market events. Well, maybe I don't know or understand something, but in theory?
There is only one way to find out.
Finally, at least publish something.
Let it be less than ideal and without plushkas (if necessary, later add), and immediately see the demand + feedback from users will go and it will be clearer in what direction to dig next.
The sooner you do it, the more time you save (or rather, less time you lose... :(
I would have given a lot for such advice in my time :)
Well, well... Go for it, Peter.
You're right about "degradation", but I think you're being presumptuous about "pulling users".
But, go ahead. There might be someone who knows how to program, but who trades "hands on".
It's not possible. Those who know how to program will surely make an assistant in MQL5 and spend only 1-2 weeks studying MQL5 trading operations.
As for the semi-automatic robot, in a few hours I will make a video and show you how a modern automated robot that can work in semi-automatic mode as an Expert Advisor looks like.
And you don't need to reinvent complicated panels for that, but make it very simple so that it's clearer to everyone.
Today's users are degraded by the grail of testering. They need to be pulled towards a little complexity and responsibility for their actions. Otherwise, a complete degradation of algotrading.
I don't see any other future for the algotrading niche. Honestly, I don't see...
So much pathos... I see raised hands of grief ;)))
You, Petya, really like the role of messiah.
Everyone's degraded... what's the world coming to... your mission, your destiny is to lead a degenerating humanity to a bright future of algotrading. There's already a diagnosis here. Off the top of your head...
Petya, don't play dumb.
There is something about mql oop that I personally don't like. Any "empty" object takes 16 bytes. Plus its pointer takes 8 bytes. Total 24 bytes per 1 item, not counting data. If you do a properties matrix instead, you can replace an "empty" object with 6 ints, each of which can store almost anything except strings (for time or price an int is enough in 99% of cases)
And dynamic_cast type conversion operation isn't cheap in terms of speed. So the method of the topicstarter (I haven't seen it, of course, but theoretically) may work faster and take less memory than analog with OOP.
Ilya Malev:
So the method of topikstarter (I haven't seen it, of course, but theoretically) may work faster and take less memory than OOP analogues.
It can't, the "kernel" of the topicstarter is an array of strings of immense size, and to speak about efficiency of such approach is unrealistic, even theoretically.
And the dynamic_cast type conversion operation is not cheap in terms of speed. So the method of the topicstarter (I haven't seen it, of course, but in theory) may work faster and occupy less memory than its OOP analogue.
So no one argues that direct access to a huge global array is faster than all these interface contrivances and type conversions. We can also think of design patterns, e.g. Visitor with double dispatch - there is a heck of a lot of overhead there.
However, all this is compensated by the convenience of support and modification. Unfortunately, maximum transferring of any thinking effort to computer has been mainstream programming development for a long time. It reaches a point that the sum of an arithmetic progression is calculated by means of a loop instead of using the well-known sum formula. In that sense, I agree with Peter that people are "degrading".
But, alas, there is no choice - either you "degrade" with everyone else, trying not to do it so fast, or you are hopelessly behind. And the fact that your programme is ineffective is of little importance.
Here I even see an analogy with competition in biology, in relations between predator and prey. The hare, running away from the wolf, is in fact competing not at all with the wolf, but with other hares. He does not need to get away from the wolf as fast as possible. It is much more important for him not to be the last to run away from the wolf. Because if he is the last to run away - he will be eaten, but if he runs away faster than everyone else - he will spend more energy than necessary, and it can be spent on more useful directions.
So it is with all sorts of programming technologies... The most efficient way to program in assembler, but it requires so much effort that it makes no sense - the energy is better spent more productively, even if the code is not so efficient. Peter's array with global access is of the same sort. Accessing it is efficient, but remembering what lies where and how to access what takes too much effort.
It can't, the "core" in the topicstarter is an array of strings of immense size, and it's unrealistic, even theoretically, to talk about the effectiveness of such an approach.
Is it really an array of strings or is it a figure of speech? If the data is represented by mql (string) strings, there's really no chance...
Accessing it is efficient, but remembering what lies where and how to access it takes too much.
When the "kernel" is ready, you can spend a relatively small amount of effort to stick to it a convenient interface that solves all the problems of "clumsy" presentation and access to information. Although this is an idle talk, as I understand it, TC has not published his codes and who knows if they are in nature at all :) Or has he posted them? Honestly, I couldn't get through all 38 pages
Also, a method that is solely confined to 'semi-automatics' is of no value by definition. Although it can help to occupy a local, limited niche in the product and freelance market