Packing Values
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?
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).
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).
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.
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
So each number would be x/255
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 nmiQuote: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
Popular Topics
Advertisement