NormalizeDouble paradox - page 2

New comment
 
transcendreamer:
The pattern breakage is that even after normalisation there are still tails!
There are no tails after normalisation... Don't mislead people.
 
VOLDEMAR:
No tails after normalization... Don't mislead people.

I don't enter .... but I have

the situation is like this: I normalize a number double, write it into a global variable of the terminal, then read it, normalize it again and get tails!

finally - I have no power to catch these tails - I just cut them off forcibly using DoubleToStr(current,2)

 
transcendreamer:

I don't enter .... but I have

the situation is like this: I normalize a number double, write it into a global variable of the terminal, then read it, normalize it again and get tails!

as a result - no energy to catch these tails - I just took and forcibly cut them off using DoubleToStr(current,2)

If you normalize variable double, for example, to 5 characters, then the variable will store 5 characters, in the case of raprinters and stuff, you convert the variable to a different data type, which can cause tails.

But there is no tail in double after normalization...

In order not to get a crash, you need to do normalization at application points, in the course of calculations you don't have to...

 
VOLDEMAR:

If you normalize a double variable to 5 digits for example, the variable will store 5 digits, in case of reprintering and other things you convert the variable to another data type and a tail may appear as a consequence.

but there's no tail in the double after normalization...

In order not to get a crash, normalization should be done at application points, you may not do it in the course of calculations...

That is, if I do, for example, a transformation
(string)current

then it can give tails exactly during this conversion?

did not know

thanks!

 
transcendreamer:
That is, if I do, for example, a transformation
(string)current

then it could give tails precisely in this conversion process?

didn't know.

Thank you!

Yes it can, DoubleToString(, 5) is correct
 
stringo:

NormalizeDouble works exactly like this (and has always worked like this since the first MQL)

The number is multiplied by 10 to the power of digits, converted to integer form (discarding the fractional part), and then divided by 10 to the power of digits

What's the problem here? Is there a pattern break?

Is the fractional part thrown away? Rounding is done by.

NormalizeDouble(1.25,1) = 1.3

 
Integer:

Is the fractional part discarded? Rounding is performed.

NormalizeDouble(1.25,1) = 1.3

Yes. I forgot to mention rounding. Rounding is applied when getting a whole number.
 
transcendreamer:
So if I do, for example, a conversion
(string)current

then it could give tails precisely in this conversion process?

didn't know.

thank you!

Not really. Binary system != decimal system. Binary decimal places are 0.5 / 0.25 / 0.125 / 0.0625 / 0.03125, etc. It is not possible to add up all the decimal digits from these bricks. For example it is impossible to put together a decimal number 0.3 exactly (you can only put together an approximate value), in binary system it will either be a little less or a little more. This is how this tail appears.

Only numbers divisible without a remainder by 1/2^each power are represented accurately.

In other words, we distort numbers when we try to represent decimal numbers in binary form.

 
Such an analogy:
We are used to the fact that not to write down exactly the result of an operation 1/3 will have to round up. But in the ternary system there is an exact representation of the operation == 0.1. If our native system was ternary and the pc worked with decimal, we would be surprised at the rubbish in bits when converting back to ternary the number 0.1troic.
 
pavlick_:
Such an analogy:
We're used to not writing down exactly the result of a 1/3 operation we have to round up. But in the ternary system there is an exact representation of the operation == 0,1. If our native system was ternary and the pc worked with decimal, we would be surprised by rubbish in bits when converting back to ternary the number 0.1troic.

That's true.

But for some reason, even a penny calculator can read a number from memory and return exactly what was written there.

You write down a fraction 1.23 and get back exactly 1.23 without any tails.

And here's the trick.

in theory, the user should be free of such a routine as presenting the number in binary format

<bore mode off>.

123456789...12
New comment