[ARCHIVE] Any rookie question, so as not to clutter up the forum. Professionals, don't pass by. Nowhere without you - 3. - page 248

New comment
 
Roman.:
ERR_INVALID_TRADE_VOLUME 131 Incorrect volume - get to know this form and set the volume "right" according to your account type, for example in micro accounts the volume is usually 0.01 lot, in 'classic' accounts = 0.1 lot... Enter a constant value of 0.1 lot into the order opening function and check it out...
EA trades a specific % lot from ekvit, i.e. I can only enter percentage like 10, 5, there is no option to enter lot 0.1 or 0.01. This problem has only occurred with a 4 digit broker.
 
MeTrade:
MaxZ:
Have you tested on weekdays? Is the spread floating?
Optimised all week, tested tonight and this morning. Is that a problem?
You didn't answer my question about the spread.
 
Why is this alert popping up? I spent a lot of effort to find out that when comparing a digit with a fractional part, I need to normalize it with NormalizeDouble(). But I decided to try it for fun today and the alert pops up! What are these glitches? Or not glitches?
      if (1.3320 == 1.3320)
         Alert("Ku!");
 
ScioMe:
Why is this alert popping up? I spent a lot of effort to find out that when comparing a digit with a fractional part, I need to normalize it with NormalizeDouble(). But I decided to try it for fun today and the alert pops up! What kind of glitches? Or not glitches?
What glitches are there? These constants are equal. The condition is satisfied.
 
MeTrade:
The EA trades with a certain % of the ekvit, i.e. I can only enter a percentage, e.g. 10, 5, there is no option to enter a lot of 0.1 or 0.01. This problem has only occurred with a 4 digit broker.
this problem occurs only in 4-digit brokers: "...i can only enter a percentage, e.g. 10, 5" - so your calculation is done without volume normalization before opening an order, i.e. in the end, your 10 or 5 percent results in 0.123 or 1.548 lots, which causes error number 131, please correct the function for lots calculation or ask a telepath, since not enough "input" (raw) data on the subject ...
 
ScioMe:
Why is this alert popping up? I spent a lot of effort earlier on trying to figure out that when comparing a digit with a fractional part, I needed to normalize it using the NormalizeDouble() function. But I decided to try it for fun today and the alert pops up! What kind of glitches? Or not glitches?

1). The compiler can simply ignore this condition (if statement).

2). If, however, the compiler doesn't ignore this condition, it will write each number to memory and allocate 8 bits for each number. It compares the numbers, not as we do with our eyes, but bit by bit. The numbers in memory are the same and the condition will hold.

I am very surprised by your question, because I can not understand how these two numbers (two records) are not perceived as equal?

 
MaxZ:
You didn't answer my question about the spread.
I tried it on a 4-digit terminal with a fixed spread, everything is OK. But another problem appeared, error number 131, which did not happen on the 5-digit terminal.
 
MeTrade:
Following your comment, I tried it on a 4-digit terminal with a fixed spread, everything is OK. But another problem appeared, error number 131, which did not happen on the 5-digit terminal.
I have to sit here and guess! :))) I'm sure you will solve the other problems as well.
 

Please advise how to do this correctly. My MM calculation function is complex and in one part of it, when calculating the lot, the function returns 0.18 as a maximum possible lot and you can open either 0.1, 0.2 or 0.3, i.e. the step is 0.1.

If I normalize the lot it is rounded down to 0.2 and the order is no longer allowed, although the maximum allowed lot is 0.18. What is the correct way to round it down or to normalize it correctly?

 
MaxZ:

""""...
Я очень удивлён был Вашему вопросу, так как не могу понять как можно два эти числа (две записи) воспринять не равными??""""


Been struggling with the problem for a while now. It almost broke my brain! The problem was this: I needed to perform an equality condition in if (). We were comparing real numbers. I couldn't get an alert, I was wondering what the hell was going on. These numbers, you can see with the naked eye that they are equal! But the terminal wouldn't print it. I finally suspected that something was amiss, but I couldn't figure out what was wrong. I need help from the mql4-community. I asked a question here, and thanks, the experts (it seems Roman and other good people) have responded that when comparing real numbers, I need to normalize them with NormalizeDouble() function. It helped. But today I've tried it and what's wrong? They are safely compared without normalization. Anyway, I've come to a conclusion that sometimes they are compared and sometimes they are not so I'd better normalize them to be safe.
1...241242243244245246247248249250251252253254255...652
New comment