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
"Apotheosis" I consider one expression by fxsaber, about which he himself could not say how it works, stating simply that "the code has been repeatedly tested, and it works". That, in my opinion, should not be the case:
This code checks ifan otfFilingTypeorder can beexecuted, and returns it if it is available on strSymbol, otherwise it is correct.
I have absolutely no idea how it works. And only rely on fxsaber's authority.
Maybe someone can explain ?
To understand it, just take apart this cumbersome return expression into its components.
Your example from "the end justifies the means"
by the way this code is just like spaghetti, but considering it's probably the most useful author in kodobase right now and I myself use his codes as is, let someone else critique
by the way this code is just like spaghetti, but given that it's probably the most useful author in kodobase right now and I myself use his codes as is, let someone else critique
it's not about criticism, i'm trying to figure out what it can do.... But as shown by the interview, and@fxsaber himself admitted - nothing but headaches
SZZ: it is highly probable, that initial variant of the small monster looked more clearly ;)
ZS: high probability that the original version of the little monster looked more obvious ;)
Took it from ZIP (contains the very first release).
But after that more and more functionality was needed, and the code was slowly getting fleshed out. It was different with the Filling function. Nothing was fleshed out there, it was written at once.
Only the compiler knows exactly what it will do. Modern compilers have staggering euristics. They adapt to the average coder and already know better what he or she needs. The best thing a compiler can do is write simple, straightforward code with short functions. It is easier and more efficient for the compiler to analyse the source code graph consisting of many function nodes to build the resulting program. It will only have a positive effect on productivity since the needed functions will be locked into all the right places.
You're absolutely right.
If we're talking about MQL5, you can forget about the "optimization" methods of 10-20-30 years ago. You need to write the most readable code. It is it, and not the hacker stuff and pure smartassery.
Why?
Because the compiler will go through 5-10 cycles of code reordering, it's amazingly clear and concise, not to mention the use of dozens of optimization patterns.
The MQL5 compiler is amused by human attempts to make +2% speed.
This is a work of art actually. 8 roots were calculated in 4 calls of the assembler command. Two double numbers were calculated in one call.If you're interested, check out how math calculations go without branching and one command (128 bits of data) calculates two roots at once
This code turns into the following assembler SSE code:
The general conclusion: mathematics has won in MQL5 due to perfect optimization. It's not arrays that lose here, but mathematics wins.
Why is that?
On the contrary, it's much easier with two "ifs" than with the "or" operator.
It's easier to trace one condition first, and leave the function if it's true, and then check the other condition, and also leave if it's true, than to try to figure out the result of a complex condition with logical "or" (which can be confused with "and"), and trace both ways of return.
It's pretty funny to read below that "the justification for such is debugging", because it means that such code is much more understandable (otherwise why is it in debugging ?).
"Apotheosis" I consider one expression by fxsaber, about which he himself could not say how it works, stating simply that "the code has been repeatedly tested, and it works". That, in my opinion, should not be the case:
This code checks ifan otfFilingTypeorder can beexecuted, and returns it if it is available on strSymbol, otherwise it is correct.
I have absolutely no idea how it works. And only rely on fxsaber's authority.
Maybesomeone can explain ?
I once sat down and took it apart step by step, seems to have needed a pen and paper)
Why this parsing was useful - I understood that in case of change of enum structure everything will be broken) since integer relations of enum values are used (which according to the idea of enumerations itself should be encapsulated). I try to avoid this myself, at most the more-less ratio. For those who deal with WinAPI, it is probably familiar.
To understand, all you have to do is take that unwieldy retournee expression apart.
Yes, that's what I tried to do. But, there wasn't enough motivation to take it apart...
Absolutely right.
If we're talking about MQL5, you can forget about "optimization" methods of 10-20-30 years ago. You need to write the most readable code. It is it, and not the hacker stuff and pure smartassery.
Exactly. I came to this conclusion long ago. But not because I think the compiler will make it better. But because the main source of problems in code is a human being himself, which means that one should write code in a way that makes it as simple and transparent as possible.
If you cannot make it "transparent", you have to write detailed comments why it is this way and not that way.
And the compiler... Even if it doesn't do it efficiently enough, it's less of a problem than a potential bug due to the fact that you don't take into account some aspects of the program.
The code is very simple and short(description). If you write it on FP, it would be interesting to compare.
Please. C# in FP style:
FP is quite crooked of course (as it was written by a crooked FP coder, in the incomplete FP language C#).But the goal is to show that on modern OOP jargon you can do it in FP too. Of course, it is limited, it is not F# or Haskell, but nobody forbids to write in FP style. Use immutability, higher-order functions, closures, mappings, etc. - you're welcome to do it all. But this doesn't make the code perfect for some reason.
s.w. The overall code structure deliberately mimics the original. Although in a good way it should be quite different in FP, without complex objects and foreach mimicking Map, but the artist painted as he could.
Please. C# in FP style:
I understand that it's a matter of habit and syntax knowledge, but I'm having a very hard time getting into the code even though I'm the original author.
Forum on trading, automated trading systems and strategy testing
Interesting opinion about OOP
fxsaber, 2021.01.29 13:39
A trifle.
Technically, it's probably an OOP. But the most primitive part of it. Couldn't do it without it, though. Possibly, dumb brain rearrangement and riveting this.