Ambitious ideas !!! - page 7

New comment
 
Mathemat:

Wrong again. Interpretation of the incoming stream is the task of the one who stands above the receiver and sets the conditions of the Game. The receiver is iron; it grinds the information according to the algorithm set for it by the Game Master. In this sense it is completely and strictly objective, because it is a dumb iron. But it is the Master who is subjective.

Do you know that information can be defined in different ways, depending on the context of the problem being solved?

By subjectivity of the receiver I mean that it can interpret the input information in an arbitrary way, according to the algorithm implicit in it. In this case the input objective information is transformed by the receiver into a subjective one. Context and everything else has nothing to do with it.
 

IgorM:

http://www.realcoding.net/article/rubric/code_optim?page=6

Thanks, not a bad site.
 
Some people think that OOP is really effective in big projects, while in small ones it's better to use good old procedural programming. But I don't agree with this opinion. If the program you want to write is larger than "Hello word" by at least one line, it is better to use OOP rather than procedural programming. From my own experience, I can say that even the smallest programs are improved, new functionality, new checks, new tasks are added to them. As the result, a program which was initially conceived as a small one turns into a real monster. It is very important to lay the groundwork here. If this is procedural programming, a project will be overgrown with a lot of unmanageable functions, pointer conversions, etc., etc. OOP is a bad thing. Write programs in it, starting with "Hello Word", and then easily and willingly develop their functionality. For instance, it is impossible to write even the smallest program in C# without using OOP. Do you think the developers of this language are short-sighted morons?
 
C-4:
But I don't agree with that opinion. If the program you want to write is more than "Hello word" by at least one line, it is better to use OOP rather than
Could you give us a concrete example to compare it with, so as not to be unsubstantiated?
 

There you go, the topic has been sidetracked, we were talking about something else:

>HIDDEN 10.11.2010 22:39

>I've been haunted by the idea of implementing a multicurrency strategy tester for a couple of years now.

If you don't like OOP, don't use it, it's a pointless argument.

 
xeon:

There you go, the topic has been sidetracked, we were talking about something else:

>HIDDEN 10.11.2010 22:39

>I've been haunted by the idea of implementing a multicurrency strategy tester for a couple of years now.

If you don't like OOP, don't use it, it's a pointless argument.


I have read all that was written here, and now I'm really afraid of MT5 because I'm obsessed with it, and I want to implement it as soon as possible.

Thanks to all those who know how to correctly (reasonably) put the brains in place.

If I think that MT5 is developed by a team of people, and we all are testing it, how much time I will spend for its implementation in MQL4? And MT4 will be dead sooner or later, it's just a matter of time. I think MT5 will last 5-10 years anyway.

 
HIDDEN:

After reading all of what has been written here, I've started to look towards MT5 because I'm really attracted to it, and I want to implement it as soon as possible.

Thanks to all those who know how to correctly (reasonably) put brains in place.

If I think that MT5 is developed by a team of people, and we all are testing it, how much time I will spend for its implementation in MQL4? And MT4 will be dead sooner or later, it's just a matter of time. I think MT5 will last 5-10 years anyway.

At the moment in the MT5 tester, there is one insurmountable (at least for now) obstacle, which may put it (for some users) off, it is the impossibility to set for testing/optimisation own (third party) history.
 
xeon:
At the moment, in the MT5 tester, there is one insuperable (at least for now) obstacle that may give up on it (for some users), it is the impossibility to use your own (third-party) history for testing/optimization.


Alas, there are a couple of "sensitive points" in MT5 - multicurrency indicators - very unstable working in the tester, it is hard to debug multicurrency indicators because of the need for independent loading of arrays of timeseries - not done yet, but soon I will - I will move the calculation of multicurrency indicators to the Expert Advisor itself - then the problems should go away

SBS: thanks to the topicstarter for understanding - we got pretty busy in his topic :), with the implementation of a multi-currency tester in MT4, there are no particular problems - decent examples on the forum, but as a fully functional tester will not work, and strive to create your own tester - wasted time - with the same success, you may analyze multi-currency trading in the same Exel

 
IgorM:


alas, there are a couple of "delicate issues" in MT5 - multicurrency indicators - they do not work confidently in the tester, it is hard to debug multicurrency indicators because of the need for independent loading of time series arrays - not done yet, but soon I will - I will move the calculation of multicurrency indicators to the Expert Advisor itself - then the problems should go away

Pumping history from the MQ database is easy, especially as there is a ready-made example: - https://www.mql5.com/ru/docs/series/timeseries_access

p.s. if i understood the task correctly...

 
xeon:
At the moment in the MT5 tester, there is one insurmountable (at least for now) obstacle that may put an end to it (for some users), which is the inability to substitute your own (third-party) history for testing/optimisation.


That's a given. Beginners don't really need it, but in real trading it's a necessary thing.

123456789
New comment