So, sin(a) and -sin(1-a) should be equal, according to trig identities. When dw complained that sin was not symmetrical, I set up a little test bench and found what seem to be two bugs, possibly related.

All the test does is iterate 'a' from 0.0 to 0.5 by 0x.0001 and compare sin(a) to -sin(1-a) and note where they aren't equal. Here's an excerpt:

    a      sin(a)   -sin(1-a)
--------- --------- ---------
 0x.3528   0x.0903   0x.0903
 0x.3529   0x.0903   0x.0903
 0x.352a   0x.08fd   0x.0903 fail
 0x.352b   0x.08fd   0x.08fd
 0x.352c   0x.08fd   0x.08fd
 0x.352d   0x.08fd   0x.08fd
 0x.352e   0x.08f6   0x.08fd fail
 0x.352f   0x.08f6   0x.08f6
 0x.3530   0x.08f6   0x.08f6
 0x.3531   0x.08f6   0x.08f6
 0x.3532   0x.08f0   0x.08f6 fail
 0x.3533   0x.08f0   0x.08f0
 0x.3534   0x.08f0   0x.08f0
 0x.3535   0x.08f0   0x.08f0
 0x.3536   0x.08e9   0x.08f0 fail
 0x.3537   0x.08e9   0x.08e9

Two things jump out at me here:

First is that it is, indeed, not symmetrical in one out of four cases.

Second is that the computed value is the same for every group of four lines, even though the angle is (subtly) different.

I could fix the failures by using -sin(0x.ffff-a) instead of -sin(1-a). I'm guessing this is just a straight-up bug in either the index selection for a lookup table or in the table itself. Probably the latter, unless the table is only for the first quadrant and the index is signing/mirroring with an off-by-one error.

What I don't get is why the bottom two bits of the fraction seem to be irrelevant. Is it a lookup table with only 16K entries?

(Same thing happens with cos(), btw, but you have to mirror the angle value across the y axis instead of x.)

Over to you, zep.