GP2X Fixed Point Class


EDIT uhm.. I have to rethink some things...

2ND EDIT okay... a variable precision is kinda ugly to code. I try a signed 16.16 now
 
I) I'll use rafb/paste now, it's just easier to read. MUL and DIV now have a range check (set to MIN and MAX values) und use long long as intermediate. ADD und SUB still wrap around.
Fixed Point Class C++

II) I keep the question if parameter passing by value or reference is better to you guys. I don't feel like reading gcc's ARM ASM. In case we have tp bloat the class more, pass by refernece becomes a must anyway.

III) I decided to fix magnitude.fraction to 16.16 for now and make it variable after everything works.

IV) I use normaly a degree sinus LUT with 360 fixed entries. This need rad->degree conversion or natively working with degrees what I do anyway. A precision of 1 degree should be enough for 2D stuff. Any comment on this or simple ideas to have a small but precise LUT(s)?

V) I did not understand the square root code posted earlier, I'll look for solution (any hints?). But a sqrt() would need a NaN value (root from negative value) as DIV by zero should already have. As we are on it, saturation anyone?
 
I think a solution is to assume that sqrt always operates on positive numbers... if you're taking a square root of a negative, chances are there's already a problem. Division by zero could return the maximum representable value, and again, it's one of those things you try to avoid anyway.
 
rixed posted on Oct 19 2006 at 01:05 AM said:
rabidcow posted on Oct 18 2006 at 11:22 PM said:
I would say don't bother making it pass by reference. If you do, check the compiled code to see if it actually passes the address rather than a copy.
You'd better check that the compiler don't actually code a function call at all...
Oh, right... good point.

synkro posted on Oct 20 2006 at 05:00 AM said:
IV) I use normaly a degree sinus LUT with 360 fixed entries. This need rad->degree conversion or natively working with degrees what I do anyway. A precision of 1 degree should be enough for 2D stuff. Any comment on this or simple ideas to have a small but precise LUT(s)?
You only need a quarter revolution for sine. (and then reuse the same table for cosine) I recommend using a power of 2 instead of 360 (I use 1024), because it makes some of the math slightly more efficient. You still need conversion from radians to revolutions, but it's just pi and shifting.

synkro posted on Oct 20 2006 at 05:00 AM said:
V) I did not understand the square root code posted earlier, I'll look for solution (any hints?). But a sqrt() would need a NaN value (root from negative value) as DIV by zero should already have. As we are on it, saturation anyone?
Division by zero should automatically throw an exception or signal or something. I think the most common thing to do with sqrt of negative is to just short out and return 0. It might be more interesting to treat the number as unsigned and get an extra bit of range.
 
Last edited by a moderator:
Back
Top