NormalizeDouble paradox - page 12

New comment
 
pavlick_:
It's clear, we have nothing to talk about. And you'd better stay out of conversations if you're not responsible for your words.

Are you an idiot?

Moderators ban me for a week to be away from idiots.

 
Integer:

Are you an idiot?

Moderators ban me for a week to be away from idiots.

Ditch it, you empty-nester.
 

oh, gentlemen, this is a masterpiece! let's have a duel over fractional numbers )))))))))))

 

It is probably fair to say that tails exist only in decimal string representation of a number,

and there are no tails in the binary representation in the sense that there are no decimal places to produce tails,

but the moment the number is "decompressed to human format", the tails appear as decimal digits because the algorithm can't decide if they are significant digits or not,

so it has to be "helped" and rounded.

and in most cases, it would be obvious to a person what number to get as a result, just by looking at the "tail".

This is why I was indignant that such a simple thing is not implemented on automatic, because for most trading tasks the required precision is known a priori and it would be convenient to have a ready solution on the language level

.........................

to continue the original topic...

at first I had a suspicion that solutionDoubleToStr(current,2) is not always correct

but substituting different "tail" numbers into print and framing DoubleToStr, I made sure that all samples work fine.

I also found out that there are two identical functions in MQL:DoubleToStr andDoubleToString that seem to do the same thing, maybe one of them is a relic of an older version of MQL up to version 600 left over for compatibility?

.............................

i also thought that the binary number format may be unsuitable for high precision tasks

Maybe there are no such problems in trading, but in astronomy or physics such tricks with binary numbers are unacceptable.

1...56789101112
New comment