Why not use treat decimals as integers when converting decimals into binary floating points

I know that we should treat the digits differently before and after the decimal point when converting the number into binary, e.g., 0.625 should be converted into 0.101. For digits after decimal points, we keep multiplying 2 and get its integer part as follows:

0.625 * 2 = 1.25 ---- 1

0.25 * 2 = 0.5 ---- 0

0.5 * 2 = 1 ---- 1

However, this method is not feasible for numbers like 0.1, since the loop is infinite and will give results like 0.0001100110011..., which leads to loss of precision.

So, why not we just treat the decimals as integers by removing the decimal point? E.g. for 0.625, we just directly calculate the binary representation of 625, and record the exponent just as the float type does (10^-3 here). This method can prevent the loss of precision for many cases, and it perfectly simulates how human calculate decimals.

If the original decimal is long, we can just cut it at maximal length, which didn't lose much precision. I don't really know why we must use "mulitply 2" method, which introduces errors for simple numbers like 0.1.

I've tried to convert many decimals into binary, and my method works better than the "multiply 2" method in most cases. Please tell me what I omitted in this process.

Please tell me why I'm wrong. Thanks!

what you proposing is called fixed point with power of 10 scaling factor. Its doable and its also used to prevent rounding errors (for example for currency computations)

however using normal binary representation (or power of 2 scaling with fixed point) is faster and much more convenient (even from HW perspective) as it simplifies many operations (*,/,pow,log,exp,...)

Also this same rounding problem arises with decadic base too just try to write 1/3 in decadic ... its also never ending series of digits ...

1/3 = 0.33333333333333333333333333...

> However, this method is not feasible for numbers like 0.1, since the loop is infinite and will give results like 0.0001100110011..., which leads to loss of precision.

Mathematically it is infinite, yet 0.1 encoded using a binary floating point is not possible. Instead we seek a nearby value like 0.10000000000000000555... or 0x1.999999999999ap-4. After perhaps 53 significant binary digits, we only need a few more to detect rounding needs.

Note that the doubling of the decimal text (the * 2) may oblige 100s of decimal digits.

> If the original decimal is long, we can just cut it at maximal length, which didn't lose much precision.

Depends if you want a good answer or the best answer.

Consider the typical smallest encodable floating point value of about 4.9406564584124654e-324 whose exact value as a decimal is ~750 significant decimal digits long.

Now consider the next larger floating point value, again ~750 significant decimal digits long.

Consider x that is half-way between those 2 as text.
Consider values near x, as decimal text (yet with the same first 750 significant decimal digits) that are slightly larger or smaller. To convert that to the best floating point value requires a maximal length of ~750 of digits so you do not lose precision and properly round up or down.

Your cut requirement is over 750 digits to always get the best answer.

In the end, real good decimal text to floating point is all done with wide integer math.