you're doing it all wrong, I say (imho)

what you're doing is comparing floating point math by hand versus floating point math by the compiler

neither one of these are fixed point math

in fixed point math you must deal with temporary precision numbers, like 24.8 can be 248, so multiply 248 * 248 and the result will be 61504, which is the correct value << 2d (decimal shift! means 1<<1d is 10), so 248 * 248 >> 1d will give you the result in the same notation of the parameters and 248 * 248 >> 2d will give you the result in the pure decimal/binary notation (i.e. 248 * 248 / 100 = 615)

That's just a very simple sample, best is if you can manage your precision to be powered-by-2-compatible, then you can use binary shift instead of division and your code will be fastest, like this:

24.8 is 248 shifted right by 1d, but let's take a simpler example: 11.5 * 11.5

11.5 is 23 >> 1b (now binary shifts, for speed!), so we should write a function that takes x and y as temporary precision numbers (I don't know if is that the real name, I knew this for a long time just by researching) and returns it in the decimal notation so:

Code:

```
int dothatmultiply(char x, char y) {
return (x * y) >> 2;
}
```

// or to return in the same notation as the parameters:

Code:

```
char dothatmultiply(char x, char y) {
return(x * y) >> 1;
}
```

// or in other temporary precision number to keep maximum precision:

Code:

```
char dothatmultiply(char x, char y) {
return (x * y);
}
```

when you call the first one with 23 as both parameters, the result will be 23 * 23 >> 2 the result would be 132, discarding some precision if you shift, but you can keep as much as precision you want if you manage to return other temporary math precision number, the precision is directly related to how many bits you offer to the calculation so ALWAYS try to best fit your numbers to deal with speed and precision altogether...

your code will be definitely faster and smaller than any floating point precision you'll ever know (as long as it's softare based), but it can render you crazy as well if you try to use one specific temporary precision number for each calculation you done! so beware of how much precision you'll need

h34r: