Trying to comprehend log table conversions
bambino
Posts: 789
The example in the manuel takes $60000000 and takes the leading bit position and gets 30 from it or ($1E) for an integer portion of the starting number. Could someone explain in more detail how the leading bit position of %01100 was set to
$1E.
And then after taking that out for a partial result somehow we come up with $0800.
Really confused here and any help would be appreciated!
$1E.
And then after taking that out for a partial result somehow we come up with $0800.
Really confused here and any help would be appreciated!
Comments
It is analogous to finding the base 10 log of, say 5000. That lies between 1000=10^3 and 10000=10^4, and the characteristic of the base 10 log is 3, so we know the base 10 log is 3.xxxx, where xxxx remains to be determined. We then would take 5000/1000 = 5, and look up 5 in a table of logarithms that goes from 1 to 10 and find there xxxx.
In the base 2 log table in the Prop Hub rom, the table is 2048 words that are the sixteen bit mantissa for an input index from 0 to 2047. To get that index, you take the 11 bits that follow the most significant bit in $60000000 in the example. Those 11 bits are proportionatly how far along $60000000 is between $40000000 and $80000000. ($60000000 - $40000000 / $40000000) Those 11 bits here are %100_0000_0000 = $0800. And that pulls the mantissa $95C0 from the table. So the base2 log is $1E_95C0. I put in the underscore to emphasize that there is a binary radix point at that position.
When you have input numbers less than 12 bits, you have to truncate and fill. There is some discussion of that in this thread: http://forums.parallax.com/showthread.php?p=642116
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 5/3/2007 4:28:51 PM GMT
Sometimes you just got to put more English on the Ball to get it in the Pocket!
I know what you mean--I had trouble with the explanation in the manual too.
Note that if the input value is exactly 12 bits, then you will use them all, the msb for the characteristic, and 11 lower bits for the table index to find the mantissa. If the input is more than 12 bits, you will be throwing away some bits on the low end (unless you use those to interpolate in the table!) If the input is less than 12 bits, then you will have to pad the index on the lsb end to make it 11 bits.
If you are doing this in Spin, note that the decode operator, >|, returns the index of the highest bit set
characteristic := >| X - 1 ' provided X>0
As an aside, the largest power of two that is less than X is given by the encode operator |<:
power2 := |< characteristic
In order to get the 11 bit table index, shift X left to get rid of the msb and maybe fill in zeros on the lsb end, then shift right to reduce the number to 11 bits and maybe drop bits off the lsb end. Like this...
index := X << (32 - characteristic) >> 21
That is the 11 bit index into the Hub table.
There is a quick function called bitlog(X) that uses linear interpolation for the fractional part, instead of the table lookup. It is plenty accurate for things like vu meters.
bitlogX := (characteristic << 11) | (X << (32 - characteristic) >> 21)
That is a 16 bit value that hits right on for exact powers of 2, but uses linear interpolation for the mantissa. Note that the linear interpolation value is precisely the index you would use for lookup in the HUB table!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I was looking to see if it was right for my app, and although I still plan to fool around with it, I believe my multiply and Division routines will be OK. I was hopeing to speed things up some , but I really don't want to lose anymore resolution. The interpolating you mentioned is another gray area for me. I don't know if riding the learning curve and the extra code is going to pay off. And I am also getting ancious to ship this thing out so I can play with some other projects for I while. I have noticed that my competition spits out there data in logarithmic values to be converted to practical values by a PC. The Propeller is fully capabable of spitting cooked data with no need for external processing. The thing that attracted me to the log was the data compression it could provide. But now I don't see it as worth the trade off.
Thanks again for the explanation.