9 replies to this topic

[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]

Heaven/TQA, on Sun Oct 16, 2011 1:53 PM, said:

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

Heaven/TQA, on Sun Oct 16, 2011 8:11 AM, said:

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 by 1NG, Sat Oct 22, 2011 9:02 AM.