Packing Values

Started by
11 comments, last by Daishim 18 years, 4 months ago
I have a scenario where I have 4 floating point values, ranging from [0 to 1). I need to map these 4 values floating values into a single floating point value from [0, 1). These combination value must be unique for the purpose that I need (ie, can't divide the 4 values by four and add them together), but I've been beating my head against the desk trying to figure something out. Anyone have any ideas?

I know only that which I know, but I do not know what I know.
Advertisement
Hi,

This depends on the precision you require in the 4 input values. For example, you can convert them to fixed-point format where 2 bits are the fractional part and 6 bits are the integer part.

This would allow you to have them bit-wise OR'd in different byte positions in a single unsigned 32-bit word.

2^2 == 4 - so your precision would only be 0.25, and integer range 2^6 = 64. Of course if you need more precision you should increase the number of bits for the fractional part - at the cost of loosing the integer range.

Hope that helps,
Cheers,
dhm

--

EDIT: just re-read your question and I see you could allocate all 8-bits for use with the fractional part because you are in the [0, 1] range. This would give a precision of (1.0 / 256.0).
Don't know if that helps, it's just a thought, but for two such numbers x,y in [0..1) you can calculate:

f = 1/x + y

So the part in front of the dot is the inverse of x and the part behind the dot is y. If x is 0 that must be handled specially. Also the sign of the number is free to use.

A problem might be that 1/x can become very big if x is small, moving y out of the mantissa. In that case you can set 1/x to a maximum (i.e. 10000).
According to information theory (and common sense) this is impossible.
Example:
An algorithm that would be able to map any four numbers [0,1) to a single [0,1) would be able to pack any numerical input by a rate of 4:1.
That's simply not possible without losing information.



Quote:Original post by dhm
For example, you can convert them to fixed-point format where 2 bits are the fractional part and 6 bits are the integer part.


There is no fractional part, but using a fixed point notation may provide a valid solution.
I would change the values into an 8 bit integer, then pack into a 4 bit integer and cast to a float.

So each number would be x/255

Insufficent Information: we need more infromationhttp://staff.samods.org/aiursrage2k/
Quote:Original post by nmi
Don't know if that helps, it's just a thought, but for two such numbers x,y in [0..1) you can calculate:

f = 1/x + y

So the part in front of the dot is the inverse of x and the part behind the dot is y. If x is 0 that must be handled specially. Also the sign of the number is free to use.

A problem might be that 1/x can become very big if x is small, moving y out of the mantissa. In that case you can set 1/x to a maximum (i.e. 10000).

That assumes 1/x is an integer.

Let's say x=0.4 and y=0.6, which means f=3.1. Clearly not the desired result.
Quote:Original post by nmi
Quote:Original post by dhm
For example, you can convert them to fixed-point format where 2 bits are the fractional part and 6 bits are the integer part.


There is no fractional part, but using a fixed point notation may provide a valid solution.

No, it cannot. Any fixed point solution will not provide a unique (e.g. a bijective injective transformation).
Without additional constraints, this problem does not have a valid solution in the domain of discrete mathematics.
Quote:Original post by nmi
There is no fractional part, but using a fixed point notation may provide a valid solution.


Yes, there is no real fractional part.

The number is just stored as a single unsigned word (for example) but you would have to write code to convert between a real floating-point type and this fixed point type and back again.

It is a common use on embedded systems - especially when your micro doesn't support floating-point :)
Quote:Original post by Brother Bob
Let's say x=0.4 and y=0.6, which means f=3.1. Clearly not the desired result.


Thanks for that hint. As I said, it's just an idea. If you cut away the fraction of 1/x you will have two distinct parts again.

It depends on what Daishi needs that packing for and if he can use casting/shifting or if he is restricted to floating point only.

The 0.8 fixed point notation will be a good choice if possible. An 8-Bit floating point notation may be another choice.

This topic is closed to new replies.

Advertisement