1

I have proceeded to state when I need to turn IEEE-754 single and double precision numbers into strings with base 10. There is FXTRACT instruction available, but it provides only exponent and mantissa for base 2, as the number calculation formula is:

value = (-1)^sign * 1.(mantissa) * 2^(exponent-bias)

If I had some logarithmic instructions for specific bases, I would be able to change base of 2exponent - bias part in expression, but currently I don't know what to do. I was also thinking of using standard rounded conversion into integer, but it seems to be unusable as it doesn't offer precise conversion. Does anybody know what is the way/basic principe for doing it? Please help.

I finally found another solution (it's in Java)

{
    /* handling -infinity, +infinity and NaN, returns "" if 'f' isn't one of mentioned */
    String ret = "";
    if ((ret = getSpecialFloats(f)).length() != 0)
        return ret;
}
int num = Float.toRawIntBits(f);
int exponent = (int)(((num >> 23) & 0xFF)-127); //8bits, bias 127
int mantissa = num & 0x7FFFFF; //23bits

/* stores decimal exponent */
int decimalExponent = 0;
/* temporary value used for calculations */
int sideMultiplicator = 1;
for (; exponent > 0; exponent--) {
    /* In this loop I'm calculating the value of exponent. MAX(unsigned int) = 2^32-1, while exponent can be 2^127 pr st like that */
    sideMultiplicator *= 2;
    /* because of this, if top two bits of sideMultiplicator are set, we're getting closer to overflow and we need to save some value into decimalExponent*/
    if ((sideMultiplicator >> 30) != 0) {
        decimalExponent += 3;
        sideMultiplicator /= 1000;
    }
}
for(; exponent < 0; exponent++) {
    /* this loop does exactly same thing as the loop before, but vice versa (for exponent < 0, like 2^-3 and so on) */
    if ((sideMultiplicator & 1) != 0) {
        sideMultiplicator *= 10;
        decimalExponent--;
    }
    sideMultiplicator /= 2;
}

/* we know that value of float is:
 *  1.mantissa * 2^exponent * (-1)^sign */
/* that's why we need to store 1 in betweenResult (another temorary value) */
int betweenResult = sideMultiplicator;
for (int fraction = 2, bit = 0; bit < 23; bit++, fraction *= 2) {
    /* this loop is the most important one: it turns binary mantissa to real value by dividing what we got in exponent */
    if (((mantissa >> (22-bit)) & 1) == 1) {
        /* if mantissa[bit] is set, we need to divide whole number by fraction (fraction is 2^(bit+1) ) */
        while (sideMultiplicator % fraction > 0 && (betweenResult >> 28) == 0) {
            /* as we needed it before: if number gets near to overflow, store something in decimalExponent*/
            betweenResult *= 10;
            sideMultiplicator *= 10;
            decimalExponent--;
        }
        betweenResult += sideMultiplicator/fraction;
    }
}

/* small normalization turning numbers like 15700 in betweenResult into 157e2 (storing zero padding in decimalExponent variable)*/
while (betweenResult % 10 == 0) {
    betweenResult /= 10;
    decimalExponent++;
}
/* this method gets string in reqested notation (scientific, multiplication by ten or just normal)*/
return getExponentedString(betweenResult, decimalExponent);
phuclv
  • 37,963
  • 15
  • 156
  • 475
user35443
  • 6,309
  • 12
  • 52
  • 75
  • 1
    Why not link in a standard C library and call `printf` or `sprintf`? – Eric Postpischil Jul 13 '13 at 17:52
  • duplicate of http://stackoverflow.com/questions/22962040/easiest-way-to-convert-a-decimal-float-to-bit-representation-manually-based-on-i and http://stackoverflow.com/questions/23540139/how-to-convert-floating-point-number-to-ieee-754-using-assembly – phuclv May 30 '14 at 14:02
  • It's very difficult to do this fast, and @PascalCuoq has already written a [blog](http://www.exploringbinary.com/correct-decimal-to-floating-point-using-big-integers/) about this – phuclv May 30 '14 at 14:03
  • Please post answers as answers, not edits to the question. – Peter Cordes Jun 30 '18 at 04:27

3 Answers3

7

Formatting a floating point number is rather non-trivial. Search e.g. for the Dragon4 algorithm (here is one result).

Very, very naively, you could try this:

  1. Handle NaN and Infinity.

  2. Print the sign (check < 0). Assume henceforth the number is positive real.

  3. If >= 1, truncate and use familiar integer formatting to print the integral part. (There should be a machine instruction for that on any hardware that has a floating point unit.)

  4. Print the decimal separator; now keep multiplying by 10 and print the truncated integral digit.

  5. Stop when you've reached the desired precision; think about rounding the last digit correctly.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • Thank you very much. BTW what about that 'very'? If it's going to be 'very' slow way? – user35443 Jul 13 '13 at 17:23
  • @user35443: Since I whipped this one up without any thought about efficiency, I imagine that this will be horribly slow. I think the point of Dragon4 was to be fast compared to libaries at the time. I don't know any details, but just imagine that my idea divides by 10 *a lot*, and that's a rather slow computation. – Kerrek SB Jul 13 '13 at 17:32
3

If it is acceptable to print as 1.d1d2d3d4d5…*2^e1e2e3, then converting a floating-point number to decimal(-ish) representation can be simple. An implementation can be found here.

If you need a scientific 1.d1d2…*10^e1e2e3 representation, then the naïve approach to repeatedly divide by 10 and extract digits from the number that you have in floating-point format. You will need some sort of multi-precision integer library. (Repeatedly multiply by 10 to extract the digits after the point.)

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
  • 1
    I'm not familiar with that language, but still thanks for your help. I think I'll choose the naive way. – user35443 Jul 13 '13 at 17:22
1

Kerrek SB's solution is correct. But you can do it faster without any loop (or less number of loops). Just multiply the fraction part with 10precision. Reducing the number or multiplications also reduces the cumulative error if you do the maths in a floating-point type. For precise conversion you have to use a higher precision floating-point type.

For example you want to convert 0.1234567 with 5 digits of precision, multiply the number with 10000 and get the int part. If rounding is needed, multiply it by 100000 and round the last number

phuclv
  • 37,963
  • 15
  • 156
  • 475
  • 2
    Such an approach is quick and easy in cases where one isn't concerned about precise rounding, nor about precision near the limits of the type. I'd suggest that the last step may often be simplified by multiplying by 200000, converting to an integer, adding one, and dividing by two. Note that it's very important to be aware that numbers may round differently in different scenarios. Turbo C 2.00 had a bug where `printf("%1.2f",99.999999996);` would determine that there were two digits to the left of the decimal point, convert the value to a string ("100.00"), and then... – supercat Jul 26 '13 at 16:07
  • ...print the result starting two digits to the left of the decimal point (i.e. "00.00"). Oops. Still, your approach ensures that even if it won't always yield precise values they're unlikely to be Just Plain Wrong. – supercat Jul 26 '13 at 16:11
  • You still need a loop to convert the `int( frac(x)*10000 )` to a string, one decimal digit at a time! But it will use integer division instead of FP multiplication ([How do I print an integer in Assembly Level Programming without printf from the c library?](https://stackoverflow.com/a/46301894)). (Unless you can use `printf` for integer formats but not float? But it has to loop internally.) – Peter Cordes Jun 30 '18 at 04:02
  • @PeterCordes If you don't want to use a loop you can use a lookup table – phuclv Jun 30 '18 at 04:11
  • 1
    I guess a 100 or 1000 entry lookup table is plausible, maybe with a 16-bit index into a packed buffer of C strings. Or where the entries *are* C strings padded to a fixed length. But 10^5 or larger LUTs are probably not reasonable for most use-cases. – Peter Cordes Jun 30 '18 at 04:21
  • 1
    With "5 digits of precision", I don't think of "0.00000" but rather 0.0000012345". Same for numbers >=1. For "123456789" I would not print "12346", but "123460000". Your answer seems to indicate you would do the former in each case. – Johannes Schaub - litb Oct 12 '18 at 20:09