Fastmath precision

2012-06-13
2013-05-23
  • Émeric Dupont
    Émeric Dupont
    2012-06-13

    From README                                                                    
    "The fast math routines are not nearly as accurate as the                      
       standard routines, but enough for the game."                                
                                                                                   
    I'm not sure where this belongs, but it's discussion-worthy.                   
                                                                                   
    I've found myself wondering how bad I had become, until I noticed that an ai   
    player with an err of 0.0 would also miss direct shots.                        
    What decided me to investigate, was the fact that after aiming slightly left   
    of the target ball, the cue ball would go to the right of said ball (without   
    any english being set).                                                        
                                                                                   
                                                                                   
    Let's consider following scenario:                                             
    Standard 12-feet snooker table (rounded to 3.6 m)                              
    Hardcoded 57.15 ball diameter (rounding to 55 mm)                              
    Cue ball and target ball are close to opposite short bands (3.6m apart)        
                                                                                   
    The angle a formed by the target ball, as seen by the cue ball, approximates to
    a = 55/3600                                                                    
                                                                                   
    (sin(a) = 55 / (sqrt(55² + 3600²))                                             
    first approximation: 55² + 3600² = 3600 ²                                     
    second approximation: sin(a) = a when a is close to 0)                        
                                                                                   
    The angle at which the cue ball can hit the target ball (from touching it left 
    to touching it right) is, assuming both balls have the same size, twice the    
    angle at which the cue ball sees the target ball.                              
    h = 11/360                                                                     
                                                                                   
                                                                                   
    Now we deal with the fastmath granularity.                                     
    From vmath.c
    #define MAX_CIRCLE_ANGLE 512

    The program starts storing n = 512 different values for sin and cos (actually
    only half of them since it uses the symmetry of sin and cos for negative angles)
    This means the granularity of implemented fastmath is g(n) = 2PI/n

    The number of different positions where the cue ball could hit the target ball
    is therefore P = h/g(n) = 11*n/720PI = 2.5
    So from that distance, there are 2 or 3 positions (depending on cue angle) at
    which the cue ball could hit the target ball. This is very low if you want to
    do anything but hitting (like wanting to be accurate).

    If you want to have at least P different positions to hit the ball, you
    need to choose n such that h/g(n) >= P
    n >= P*720PI/11

    For example, to have at least 20 possible angles (10 on each side of the
    target ball), you need n >= 4113

    Of course at the cost of the memory (4113*sizeof(float) bytes), but I would
    really consider
    #define MAX_CIRCLE_ANGLE 4096
    as a minimum value.

    Recomputing a different fast_cossin_table according to the table size would
    also be a valid option.

    Was this fastmath implementation specifically tailored for target devices
    having well-known limitations (I'm thinking of the WeTab, for example) ? Or
    did performance issues occur, that forced to switch to a less
    computing-intensive implementation of math functions ?

     
  • Thank you very much for your work on the math routines. And yes, here is a good place for discussing things like this.

    I've used the fast-math routines on some machines like Netbooks and yes the WeTab. And not only the fast-math routines gives really a boost.

    OK, we speak about 512 or 4096 or 8192 table entries. That are 2 KB, 16 KB or 32 KB memory. That is not the problem. I've tested with 512/4096 and 8192 table entries on slow machines. Here ist the result in comparison to the standard math.h:

    512 entries are three times faster
    4096 entries are also three times faster
    8192 entries the same

    For comparisation: on very fast machines it's the same.

    irony of math with computer: The fast exp function (only used with the lensflare) works on slow machines up to three times faster and on very fast machines (with pure Intel CPU) up to three times slower ;-(

    Thanks. I put a table with 8192 entries in size into the fast cos/sin functions into vmath.h. Let's test with it.