MQL4 MathCeil() intermittantly returns wrong result - page 2
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
Hi again Jjc,
LotStep is absolutely out of our discussion.
We are talking only about common rules of lot size computation.
"Common rules" means "common sense rules".
And further:
1. let "lot" is lot size of computed order;
2. let "MinLot = 0.10", that is impossible to open order with "lot < MinLot";
3. let the system uses in lot size computation following parameters:
3.1. predefined value at risk limit in percents of account equity,
3.2. current account equity value,
3.3. computed by trading strategy stop loss distance;
4. purpose of this computation is to limit risk by lot size limitation;
5. let lot size computation for given parameters returns "lot = 0.02";
6. it is means that for given parameters "lot = 0.02" is lot size limitation value;
7. any value of "lot" variable greater than "0.02" oversizes predefined risk;
8. statement "if ( lot < MinLot ) then lot = MinLot" oversizes predefined risk to 5 times;
9. for example, if predefined order VAR limit is 12%, then in case of "lot = 0.02" statement of p.8 accepts VAR equal to 60%;
10. must be "if ( lot < MinLot ) then lot = 0".
Best regards,
Ais
Thanks so much for your explanations on the FPP, I am making ASSumptions in my code about precision that I SHOULD KNOW BETTER about.
Everyone has blind spots based on their past experience. Personally, I've written a lot of code over the years in VB6 and VB.NET. For example, it's an effort to remember that a cast from a double to an int in VB rounds to the nearest integer, whereas in C, or C#, or MQL, or indeed anything else, the same type of cast always rounds down.
I am assuming that NormalizeDouble is far cheaper than MathFloor(56.000000000000007).
Hard to tell. In an interpreted language such as MQL it's difficult to work out what the cost of ex4 code calling a built-in function is versus the cost of it being called by another built-in function. But the cost of such an internal call should be trivial.
I agree that the Double Normalization should be pushed into the MathFunctions() where it makes sence
I'm not actually certain my suggestion is a good one, but it is odd that various MQL functions use more precision that you can display and therefore verify (because DoubleToStr and NormalizeDouble are both documented as capped at 8DP). As you know, I've offered a pragmatic defence of MQL's use of processor-native doubles on the grounds of speed. But that doesn't necessarily mean that the platform shouldn't do the trivial job of adjusting them to something like 8DP at the point of entry and exit from API functions. Extending the example, I'm not convinced that OrderSend() should require you to (or, at least, the documentation says that it requires you to) do your own rounding of prices to MODE_DIGITS.
JUST TO CLARIFY my function above is to return the percent lots of remaining "global" lots on order.
MathCeil is proper call to return the higher of two numbers of lots e.g. 25 would be _lots = 13 and global lots would get lots =12.
I think this means/confirms that you want to err on the side of caution when calculating how much to close. For example, if lotstep and minlot were 0.10, and you were (long or short) 0.10, and you asked the function to calculate 25% of the position for closure, it would return 0.10 rather than zero. There's nothing less risky than being out the market. It's one of the areas where risk management isn't necessarily quite the same as money management.
5. let lot size computation for given parameters returns "lot = 0.02";
6. it is means that for given parameters "lot = 0.02" is lot size limitation value;
7. any value of "lot" variable greater than "0.02" oversizes predefined risk;
It's with trepidation and respect that I quibble with the master, but... If you're opening a position, then I absolutely agree. But if you're closing a position - as we are here - then an "over-reduction" in the position size decreases risk. It may cost you an undesirable and arguably unnecessary loss, but that's different to risk. Risk = uncertainty. The smaller your position, the less uncertainty. For example:
1. You are long (or short) 0.10.
2. Minlot and lotstep are 0.10.
3. You want to "close 25%" of the position.
4. You have two choices:
4a. Round down, and close nothing
4b. Or round up, and close everything.
5. Closing everything reduces your risk to zero. Closing nothing leaves your risk as it is. Rounding up may be many things in the context of closing orders, but it's not riskier.
The only exception I can see if is minlot > lotstep, and also the broker enforces the very literal potential definition of minlot which I've linked to before. If both these things are true, then you could potentially close a position of e.g. 0.02 long by going 0.10 short, leaving you 0.08 short.
Hi Friends,
"Risk=uncertainty" is a crude simplification of risk.
Modern risk concepts, especially financial concepts, define risk as:
"Risk = Probability of loss x Size of loss".
Probability of loss is a consequent of uncertainty.
Size of loss is a exposure to threat.
Manipulations with order size let uncertainty as is without change, affecting only to market exposure.
Smaller position or greater, loss probability as uncertainty stays the same.
Best regards,
Ais
"Risk=uncertainty" is a crude simplification of risk.
Modern risk concepts, especially financial concepts, define risk as:
"Risk = Probability of loss x Size of loss".
Yes, I was simplifying. Apologies for being "crude". But probability of loss can't be altered by closing out more or less of a position (unless you think your activity will move the market). Size of potential loss is affected. Therefore, closing out more rather than less of a position reduces risk, even under your own definition. No? Or am I still being too "crude"?
[ADDED...]
Strictly, you have a vast spread of potential outcomes, based on either or both of ex-post and ex-ante data. It's possible that, in some scenarios, you have sufficient confidence that leaving a position open is optimal. But there's just no way that, in the context of a general discussion such as this one, you can generalise that occasional condition to a categorical rule such as "you should always err on the side of not closing positions". The safe haven has to be with, er, crude and un-modern risk assessments that being out of the market is safer than being in it. Ultimately, we're talking here about a very generic function for calculating the amount of a position to close, not some very, er, modern and un-crude risk assessment model. We're also wildly off-topic - apologies to johnmclauglin in particular.
My first post just means "MQL4 MathCeil () always returns 100% correct result".
My first post just means "MQL4 MathCeil () always returns 100% correct result".
As you will. I just feel very honoured - really, honestly - to have got a series of responses from you which doesn't consist of your usual numbered lists. It's like a compliment from the gods to the mortals. As though Jehovah had got to the end of the Ten Commandments, and then said, "Ohy, by the way.."
Thanks so much to both of you for your understanding and aid
John