Double vs FLOAT - unclear MathFloor error - page 6

[Vladislav Andruschenko]

fxsaber:
Yes.

Thank you

[fxsaber]

Vladislav Andruschenko:
Thank you

There was a solution on the first page... it's already on page six.

[Dmitry Fedoseev]

fxsaber:
Then why does it work without normalisation and MathFloor?

If the input is 0.95?

[fxsaber]

Dmitry Fedoseev:
If the input is 0.95?

I don't get it.

[Alexey Viktorov]

Vladislav Andruschenko:

I may not be quite sure what to get, but look at this option

void OnStart()
{
double ask2 = 1.55557, ask3 = 1.55558, bid = 1.55555;
  Print("(ask2 + bid)/2 = ", (ask2 + bid)/2);
   Print("(ask3 + bid)/2 = ", (ask3 + bid)/2);
    int avPrice_2 = (int)NormalizeDouble((ask2/_Point + bid/_Point)/2, 0);
   int avPrice_3 = (int)NormalizeDouble((ask3/_Point + bid/_Point)/2, 0);
  Print("avPrice_2 = ", avPrice_2);
Print("avPrice_3 = ", avPrice_3);
}/*******************************************************************/

result

2017.02.27 00:03:54.453 00 (EURUSD.m,H1)        (ask2 + bid)/2 = 1.55556
2017.02.27 00:03:54.456 00 (EURUSD.m,H1)        (ask3 + bid)/2 = 1.555565
2017.02.27 00:03:54.456 00 (EURUSD.m,H1)        avPrice_2 = 155556
2017.02.27 00:03:54.456 00 (EURUSD.m,H1)        avPrice_3 = 155557

[Vladimir]

"Take Ask and Bid. and calculate the average price. If the spread is odd (3,5,7,9, etc.) then equate the average price closer to the Bid."

The task is not set:

- What does an odd spread mean. 1,3,...,9 times Point or 1,3,...,17,57 times Point? Roundings do work within unit segments...

- what does "closer to the Bid" mean? Particularly if the spread is 43 times Point, for example. Are we talking about equating the Bid to what?

You need clarity in the problem first, only then can an unambiguous decision be made.

At the same time, since we are talking about even/odd numbers, it would be logical to go to integers, where this concept makes sense.

double Ask,Bid,Middle; // Уже известные курсы Ask и Bid, вычисляемый средний курс
int Mash,Spr; // Множитель перехода к целым числам. Для 4-разрядного EURUSD 10000. И целочисленный спред

Mash=MathRound(1.0/_Point);
Spr=MathRound((Ask-Bid)*Mash); // Целочисленный спред
// Придаем конкретность среднему курсу.  Предполагаем, что "ближе к Бид" значит "ближайший меньший среднего арифметического Ask и Bid, кратный Point"
Spr=Spr >> 1; // Целочисленный спред, деленный на 2 с отбрасыванием остатка
Middle=Bid+Spr*_Point;

// Если предположение неверно, канва последующих разборов такая
if ((Spr &  1)  != 0)) {  // Спред нечетный
  }
else {  // Спред четный
  }

[sibirqk]

I had something similar happen in a very simple task - the script read the EURUSD opening price from the time-series into a doubled array and then wrote that array into a file. As long as the price was greater than one, everything was fine. But when in zero year the price was lower than 1, sometimes not very often, about 20 times a year, some strange things started to occur - somewhere in the 15th decimal place the 1 was cut off and all the previous ones, of course, turned into 9. It's not a big deal, but it's not nice. Normalization did it everywhere and after reading and before writing to the file and while recording, and converting from one array to another with normalization - nothing worked. If I add 1 when reading from timeseries, everything was ok. Eventually I got fed up with it, changed the dowble to float and calmed down.

[Vladislav Andruschenko]

Vladimir:

"Take Ask and Bid. and calculate the average price. If the spread is odd (3,5,7,9, etc.) then equate the average price closer to the Bid."

The task is not set:

In fact, the task seems to be simple? and it can be done by a schoolboy? :-) I thought so too.

But in pricing from the server, data normalisation and the rest - there are dark corners that you don't even mean.

I've been programming in mql for 9 years - and I've never had a problem with normalisation because I got it right. and accuracy to 1 millipoint has always worked correctly.

But there are tasks that require high accuracy.

And there are conditions.

Namely:

1. We take the ASC and BID price - we calculate its average price = easy? ok.
2. Accordingly, if the spread is odd (3 points for example) then we cannot divide without a remainder, right?

So, we have to normalize the price in such a way that if there is a residue (and there will be one even with an even spread! :-)) then we average the price closer to the low point, i.e. to the Bid.

For example:

• asc = 1.23455 bid = 1.23457 spread = 2 Average price: 1.23456
• Ask = 1.23455 Bid = 1.23458 Spread = 3 Average price: 1.23456
• ask = 1.23455 bid = 1.23459 spread = 4 Average price: 1.23457

And everything seems to be simple? Everything should work and I'm a fool myself? and I sat for 2 days hoping I wasn't a fool. Understanding about tails and dabbles and tribbles and bibbles..................

But! with the same formula, with even spreads and odd spreads - in some situations - the Formula didn't work . (see above) .

Including, it can work on currencies and not work on oil.

It may work on JPY and not work on USD at some point in time.

Maybe it is looking at the influence of the moon? The weather in Africa .................

But, when you are sure that the formula works, you don't notice that 1 millipipoint. and you work on..... and then "Bang, bang, bang, bang" and that millipoint, decides to run away, or call the second millipoint, Who gets in the way.

IMHO.

You can think of me as a fool, an underprogrammer, a schoolboy.... and so on.

But the fact remains.

An error occurs with different combinations of double values. At the same time, everything is clear with float.

I haven't figured it out yet. Help is very good and I always ask for help, that's normal. And I may ask the community for help in 10 years. This is normal. And I respond to a call for help if I know the pitfalls - that's normal.

Of course, after such tests, I will do "extra investigation" to understand for myself why this is the case.

Thank you all for your responsiveness and help.

[Vladimir]

Vladislav Andruschenko:

In fact, the task seems simple? And it can be done by a schoolboy? :-) I thought so too.

But there are such dark corners in prices obtained from the server, in data normalization and the rest - that you don't even mean.

I've been programming in mql for 9 years - and I've never had a problem with normalisation because I got it right. and accuracy to 1 millipoint has always worked correctly.

But! with the same formula, with even spreads and odd spreads - in some situations - the Formula didn't work . (see above) .

With different combinations - with double values an error occurs. At the same time with float everything is clear.

What does normalization of data according to Metacvotes have to do with it at all? This term means different things to programmers and not rounding at all. Read IEEE Standard 754, for example, here:http://www.softelectro.ru/ieee754.html. Unnormalized real numbers range up to 1.17549421*10^(-38) in case of 4-byte length and up to 4....*10^(-324) in case of 8-byte length, we meet them very rarely and certainly not in course calculations. If you need to call OrderSend, then round it according to the requirements of this function. There is no need to use rounding until the task requires it.

Errors occur not in double or float format, but in the operations used. The fact that the formula didn't solve the task tells you that it is not appropriate for the task. No more than that. Tell me what errors occur in a normal calculation without normalisation (this is the piece from my post above):

Spr=MathRound((Ask-Bid)/_Point); Spr=Spr >> 1; Middle=Bid+Spr*_Point;

[Maxim Kuznetsov]

Vladislav Andruschenko:

In fact, the task seems simple? And it can be done by a schoolboy? :-) I thought so too.

But there are such dark corners in prices obtained from the server, in data normalization and the rest - that you don't even mean.

I've been programming in mql for 9 years - and I've never had a problem with normalisation because I got it right. and accuracy to 1 millipoint has always worked correctly.

But there are tasks that require high accuracy.

And there are conditions.

Namely:

1. We take the ASC and BID price - we calculate its average price = easy? ok.
2. Accordingly, if the spread is odd (3 points for example) then we cannot divide without a remainder, right?

So, we have to normalize the price in such a way that if there is a residue (and there will be one even with an even spread! :-)) then we average the price closer to the low point, i.e. to the Bid.

For example:

• asc = 1.23455 bid = 1.23457 spread = 2 Average price: 1.23456
• Ask = 1.23455 Bid = 1.23458 Spread = 3 Average price: 1.23456
• ask = 1.23455 bid = 1.23459 spread = 4 Average price: 1.23457

And everything seems to be simple? Everything should work and I am a fool myself? and I sat for 2 days hoping that I am not a fool. Understanding about tails and dabbles and tribbles and bibbles..................

But! with the same formula, with even spreads and odd spreads - in some situations - the Formula didn't work . (see above) .

Including, it can work on currencies and not work on oil.

It may work on JPY and not work on USD at some point in time.

Maybe it is looking at the influence of the moon? The weather in Africa .................

But, when you are sure that the formula works, you don't notice that 1 millipipoint. and you work on..... and then "Bang, bang, bang, bang" and that millipoint, decides to run away, or call the second millipoint, Who gets in the way.

IMHO.

You can think of me as a fool, an underprogrammer, a schoolboy.... and so on.

But the fact remains.

An error occurs with different combinations of double values. At the same time, everything is clear with float.

I haven't figured it out yet. Help is very good and I always ask for it, it's normal. And I may ask for help from the community in 10 years. This is normal. And I respond to a call for help if I know the pitfalls - that's normal.

Of course, after such tests, I will do "extra investigation" to understand for myself why this is the case.

Thank you all for your responsiveness and help.

Depending on your goals, sometimes it's worth going to whole numbers altogether. It saves a lot of nerves :-) Once I had a task where I had to accurately mark up many, many levels, at first I struggled with double, but then I converted everything to integer points from 0 and everything became easy, simple and error-free.