Solved

# Decimal Representation, with a 64bit mantissa and an 8bit exponent

Posted on 2009-05-28
Medium Priority
720 Views
Hi.

I'm working on a project where we need to generate a byte stream of Dec64 with an 8bit exponent, and send via TCP/IP. The first 8 bytes are the mantissa and the 9th byte is the exponent (which is base 10) (for the techies, this is being done in C# .NET 2.0). So in practice, we're actually sending a signed 64 bit int for the mantissa, and a signed 8 bit int for the exponent.

As an example, say we have the decimal value 123.45. The mantissa we'll be sending is a signed 64bit int of 0x3039 and the exponent is a signed 8bit int of 0xFE. On the wire, we transmit the following
Bytes: 0x39 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0xFE
Binary: 00111001 00110000 00000000 00000000 00000000 00000000 00000000 00000000 11111110

So what I'm looking for is either a) the formula for taking a decimal value and converting it to a signed 64 mantissa and a signed 8 bit exponent or b) some c# code that can do this.

Thanks.

0
Question by:oliversk
• 4
• 4
• 3
• +1

LVL 27

Expert Comment

ID: 24497415
I don't see how you get that.  Are you using twos complement notation?

123.45  =  0.12345 x 10^3

Mantissa   ==>   0.12345  = 00001111 11110011 ...     ==>  (0.12345 x 2^63)

Exponent  ==>    00000011

0

LVL 20

Expert Comment

ID: 24498171
Maybe (M,e) rather represents the number M*10^e and this special example (0x3039,0xFE) additionally encodes the lack of precision, i.e. (0x1E2EA, 0xFD) = 123.450 is the same value with better precision?
"Normally", one would require a normaliziation 10*|M| >= 2^63 >= |M| and possibly an offset for the exponent. As of now, it seems the number format is not specified well enough.
0

LVL 27

Accepted Solution

d-glitch earned 1500 total points
ID: 24498232
I agree that the specification needs some work.

Wikipedia actually covers three cases for 123.45

http://en.wikipedia.org/wiki/Significand
0

Author Comment

ID: 24500836

So I have the formula 'value = mantissa x 10^exponent'

Such that
123.45 has a signed 64bit mantissa of 0x3039 with an exponent of 0xFE
and
-123450000 has a signed 32bit mantissa of 0xCFC7 and an exponent of 0x04.

So what I'm looking for, as in the third example in the link you sent is the formula to get the mantissa and exponent so that we can convert from the values above.

My mantissa always has to be a signed positive number, not a decimal. The formula I have allows me to convert back to the value, but I need to initially create the mantissa and exponent so I can create a byte stream.

Thanks again.
0

LVL 85

Expert Comment

ID: 24500954
What is the format of the input to this function?
Would 123.45 be given as a 6 character ascii string "123.45"?
Is it as a 64 bit IEEE 754 floating point number?
If so, 123.45 won't be represented exactly, and the closest value that can be represented would be

123.45000000000000000000000000000063108872417680944432938285222622898373856514808721840381622314453125
does that mean it should be represented as
0x1693878aae8f89b30eaa8384e02a7052cc6380cd146a6ed2b0ceeac013048d621086765b7b2b6575c885  * 10^90
0

LVL 85

Expert Comment

ID: 24501009
Or the closest 32 bit IEEE 754 floating point number to 123.45 would be
123.4499969482421875
so would that translate to 0x73 0xf6 0x3a 0x7c 0x2e 0xd3 0x21 0x11  0xf0 ?
Or do you want to round to 2 decimal places before converting?
0

LVL 85

Expert Comment

ID: 24501014
10^90 should have been 10^-90
0

LVL 20

Expert Comment

ID: 24501147
I think 10^-90 is wrong as well - after all 2^64 = 9.2 * 10^18, hence an exponent much closer to 0 should be expected -- my "guess" is
1234500000000000000 * 10^-16 = 0x1121D33597384000 0xf0

Anyway this suggests that one should determine if and how far the exponent should be biased. Without bias, the positive normalized numbers will be approximately in the range 1/10*2^63*10^-128 ... 2^63*10^127, i.e. 9.2e-111 ... 9.2e145, which is (though just slightly) asymmetric; the decision about exponent bias may be determined by the application (i.e. the range of numbers that should be representable).
0

LVL 85

Expert Comment

ID: 24501211
1234500000000000000 * 10^-16 cannot be represented exactly in binary IEEE 754 floating point, if a floating point number is supposed to be the input to the function, the true value would be more like
123.45000000000000000000000000000063108872417680944432938285222622898373856514808721840381622314453125
It the input to the function is a character string containing '1', '2', '3', '.', '4', '5', terminated with '\0'
then the function would have to be written a different way.
so we need to know how the original decimal value is supposed to be passed to the function
0

LVL 27

Expert Comment

ID: 24502473
>> My mantissa always has to be a signed positive number

There is a conflict between signed and positive.

If you interpret your 64 bit mantissa as a twos complement integer in ther range
+/-9.223x10^18, you will be able to express floating point decimal numbers with
up to 18 significant digits precisely.

One downside, is multiple forms for the same number.

123.45  ==>     12345 x 10^-2

123.45  ==>   123450 x 10^-3

What is you goal in all this?  Why aren't the standard formats adequate?
0

Author Comment

ID: 24515489
Hi.

I've attached a snippet of the spec I'm working from on this.

Thanks.
snippet.doc
0

Author Closing Comment

ID: 31586183
Figured it out from the wiki page that d-glitch posted.
0

LVL 27

Expert Comment

ID: 24517660
From your spec, the range for the mantissa is

-9187201950435737471  to  +9223372036854775807

The positive range limit is (2^63)-1 as I would expect.
But the negative range limit is not -(2^63) you would get with twos complement.
So I don't understand what sort of encoding SInt64 uses.

Similarly for the SInt8 exponent:
I would expect the range to be -128 to +127  with twos complement.
0

## Featured Post

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.