Lookup-Table Question

[Heaven/TQA]

have a look on this table. I want to store that in an nice 16bit table when transfering my code from basic to assembler... any ideas? I would prefer 8.8 fixed point format but maybe my math skills are getting old but can someone tell me how to do that?

 

thanks!

 

	  0
	  92.63157867
	  93.61702116
	  94.6236558
	  95.65217429
	  96.70329645
	  97.77777822
	  98.87640455
	  99.99999999
	  101.149425
	  102.325581
	  103.529411
	  104.761905
	  106.024096
	  107.317073
	  108.641975
	  110
	  111.392405
	  112.820513
	  114.285714
	  115.789474
	  117.333333
	  118.918919
	  120.547945
	  122.222222
	  123.943662
	  125.714285
	  127.536232
	  129.411764
	  131.343284
	  133.333333
	  135.384615
	  137.5
	  139.682539
	  141.935484
	  144.262295
	  146.666666
	  149.152542
	  151.724138
	  154.385965
	  157.142857
	  160
	  162.962963
	  166.037736
	  169.230769
	  172.54902
	  176
	  179.591837
	  183.333334
	  187.234043
	  191.304348
	  195.555556
	  200
	  204.651163
	  209.52381
	  214.634147
	  220.000001
	  225.641026
	  231.578948
	  237.837838
	  244.444445
	  251.428572
	  258.82353
	  266.666668
	  275.000001
	  283.870969
	  293.333334
	  303.448277
	  314.285715
	  325.925927
	  338.461539
	  352.000001
	  366.666668
	  382.608697
	  400.000001
	  419.047621
	  440.000002
	  463.157896
	  488.888891
	  517.647061
	  550.000003
	  586.666669
	  628.571431
	  676.92308
	  733.333337
	  800.000004
	  880.000004
	  977.777783
	  1100.000006
	  1257.142863
	  1466.666674
	  1760.000009
	  2200.000012
	  2933.333349
	  4400.000024
	  8800.000049

[Heaven/TQA]

maybe a simple DIV 256 MUL 65536?

[Rybags]

What do the numbers represent?

 

If it's something like angles, you don't have to stick with Degrees. When I was thinking about 3D calcs, my approach was to use 64 divisions per right angle rather than 90... makes things a lot easier.

 

But yes, like the idea you just posted - requantify the values such that they're spread over the integer spectrum you're using, and you shouldn't lose too much precision.

[NRV]

Well, 16.16 would be more nice for your numbers

 

You need 13 bits for your max integer value (8800), so if you are forced to 16 bit values, that gets you something like 13.3. In that case I probably would drop the 2 highest values (8800 and 4400.. this sound like Hz values ) and use a 12.4 representation, representing these max values as a "special" case in the code (and assigning them a special bit sequence..).

 

If size (and speed) is not a problem I would go for a 16.8 or 16.16 representation directly.

For the decimal part, 8 bits gives you something like "2.25 digits" of precision, and 16 bits gives you like "4.5 digits" of precision (P-M numbers use 8 bits of decimal precision by the way.. but could also use 16).

 

This is the code I normally use to transform a float value (below 256) to a 8.16 byte representation:

 

void FloatToByte3(float floatValue, int arrayIndex, bool approximate)
{
if (approximate)
{
 // 2 ^ -(16+1) , approximation, this is like adding 0.5f previous to an (int) conversion
 floatValue += 1.0f / 131072.0f;
}
unsigned char byte1 = (unsigned char) floatValue;
unsigned int decimalPart = (unsigned int) (65536.0f * (floatValue - (float) byte1));
unsigned char byte2 = (unsigned char) (decimalPart / 256);
unsigned char byte3 = (unsigned char) (decimalPart - byte2 * 256);
m_arrayByte1[arrayIndex] = byte1;
m_arrayByte2[arrayIndex] = byte2;
m_arrayByte3[arrayIndex] = byte3;
}

[Heaven/TQA]

Thanks. Need to Check how i can transform the table to a desired range. Speed will be crucial when looking up. And the table has something to do with perspective

[NRV]

Don't forget the cars

[+JAC!]

Too obvious: Human population simulation!

 

[Heaven/TQA]

haha... no... Cash Burn Rate of my new Startup... or Employees per months... or Revenue per months or... (insert every Web 2.0 marketing blabla here...)

[popmilo]

Thanks. Need to Check how i can transform the table to a desired range. Speed will be crucial when looking up. And the table has something to do with perspective

 

That perspective stuff sure sounds interesting

 

In what type of calculations are you using those numbers ?

[1NG]

1) Highest Number is 8800 and should fit in 256 ( 2^8 )

2) 2^N as factor for shifting would be nice

this means DIV 32 or DIV 64

In DIV32 the 8800 would get 255 instead of correct 275 wich is only 255*32=8160 but you have one mor bit for accuracy

 

maybe a simple DIV 256 MUL 65536?

simple DIV 64 MUL 256

or DIV 32, Max(value,255), MUL 256

 

You can interpret the resulting numbers as 13.3 or 14.2 fixpoint arithmetic (without using a sign, because all numbers are positive)

Edited October 22, 2011 by 1NG