Obviously 2^1034 is not going to fit in any existing types (and probably not even fit visually on your screen). If you really need to determine values of that precision (I can't imagine why, other than for the challenge of doing it), then you're on the right track, using string values. I would think it would be much harder to develop your own 2048-bit integer type... Good luck to ya :-)

I'm failing to see the issue here. Assuming C++, set your output stream's format and precision to the desired type and size.



You can set your precision as high as you want, assuming don't go above FLT_DIG or DBL_DIG or LDBL_DIG depending on your type. Printing digits beyond the floating point's precision is just garbage.

If you want to display all 19 digits of 2269216741329525385, then simply set your output stream's format to fixed and precision to 19 and output the value.




(As a side note, you have to go through special gyrations on Visual Studio to get a long double, it silently treats them as a 64-bit double. Hopefully you knew that already if you are looking for 80-bit floats.)

I'm not sure I understand what you are trying to achieve.

you want to convert an 80-bit floating point value into a displayable string, right ?
if so, why do you need to convert it to an intermediate integer representation? can't you just recompose the mantissa into base-10 digits, bit by bit, and then place the decimal point wherever it needs to be, padding with zeroes as necessary, based on the exponent value ? it's pretty fast, you just need a couple shifts and an integer mul per output decimal digit in the inner loop.

I currently have working code that does just this (not on 128 bit floats, but the algorithm can be generalized)

Quote:Besides, given the format of the data, it is impossible to tell how many zeros to use as padding. There probably is some trick to the integral part (notwithstanding 112-bit mantissas), but there definitely is not a trick to the fractional part.

with the base2 exponent, you can compute the base10 exponent. all this can be done into 32 bits types. the base10 exponent, will give you the decimal point's position. this is all you need to be able to emit the padding zeroes and the decimal point.

for the fractional part:
if the exponent is negative, you emit "0." + (abs(base10Exp) - 1) * "0".
otherwise, if the exponent is positive, you start decomposing the mantissa, and emitting the decimal digits (more about this later).
once you emitted 'base10Exp' digits, you drop the decimal point and resume emitting digits. if you have consumed your whole mantissa, and still have not reached the decimal point, you simly emit 'base10Exp - number of already printed digits' zeroes.

(by the way, you might not want to actually emit zeroes for padding. even when the mantissa will be entirely consumed, depending on the fp value, you can keep emitting nonzero digits for a while, to print the exact value this mantissa represents (a 3 bit mantissa with the value 0b001 will give a real value of 0.125, way above the single decimal digit that would have theoretically been emitted if we stopped emitting digits when the mantissa had been fully consumed. but that's a detail. most implementations just round the last digit and don't bother with the sub-digits that exceed the mantissa's precision...))

anyway...
about decomposing the mantissa...
if we forget about the whole integer storage story for the moment.
extracting digits from a mantissa will basically go like this:
(assuming a zero exponent, we'll generalize to nonzero exponents later)

N = 1 << mantissaBitCount
m = mantissa | (1 << (mantissaBitCount + 1)) // add the silent '1' to the mantissa. this will require special handling for denormals

digit0 = ((m / N) * 1) % 10
digit1 = ((m / N) * 10) % 10;
digit2 = ((m / N) * 100) % 10;
digit3 = ((m / N) * 1000) % 10;
...
digitn = ((m / N) * 10^n) % 10;

removing the modulos and divs:
mb = mantissaBitCount

digit0 = (m >> mb);
m = 10 * (m - (digit0 << mb));
digit1 = (m >> mb);
m = 10 * (m - (digit1 << mb));
digit2 = (m >> mb);
m = 10 * (m - (digit2 << mb));
...
digitn = (m >> mb);
m = 10 * (m - (digitn << mb));

this method will give you the real sub-digits mentioned earlier, even when you've consumed all the mantissa bits.
there are many details and tweaks that can be added to maximise precision. I don't have enough time right now to dive into the implementation details, but the rough algo should be enough.

now. the part that will be problematic for your specific case, is just that you will have to work on two u64 to represent your 112-bit mantissa:

m = 10 * (m - (digit2 << mb));

the shifts are trivial, and you just need a 128-bit integer multiply (really, a "128-bit times 10" operator), and a 128-bit integer subtraction.

with these two tools you should be able to pull it off without too much trouble.

if you're concerned about speed, this is a pretty fast method, and should stay pretty fast even if you roll a custom (128-bit,10) mul, and 128 bit subtraction:

timings (in cycles) of sprintf() and this method:


I don't know if anybody else uses something like this, but it works pretty well for me.

Quote:Original post by YogurtEmperor
iMalc: The link is handy, but for this project I need to use entirely custom coding. I will keep your link around for other projects in the future.

Why would a project require that you use entirely custom coding, regardless of the license granted with any existing piece of code and regardless of how suitable a piece of code is for your project? That doesn't make a lot of sense.