You could just take your number, inflate it by multiplying it by 128 or something, then divide by 100, multiply by 314, then finally de-inflate by dividing by 128.
N*128*314/199/128->N

The current sine and cosine routines produce 1-byte outputs, which is why the range is from -127 to 127. It uses a basic approximation that already isn't completely accurate for the output range of -127 to 127, so expanding the output range would just inflate the inaccuracies as well. If you want to inflate the output values, it's probably not that difficult to do with Axe anyways. And if he were to modify the routine to be more accurate and produce 2-byte outputs, it would require a better approximation method and would surely be a much heftier and slower routine.

Well actually it would be a bit more complicated than just multiplying by 2. For now, you would have to do something like this:

Code: (31 bytes) [Select]

!If sin(A)→B<ᴇ80
B+ᴇFF00→B
End
.8.8 fixed point result in B
When the signed division auto-optimizations are fixed, a better way will be this:

Code: (15 bytes) [Select]

sin(A)*256//256

Quote from: Quigibo on November 23, 2010, 03:04:40 pm

its only 1 byte more to multiply by two whereas it would be 4 bytes to signed divide by two.

Curious i would think, it takes more memory to go one way than the other way?  I guess some operations don't have an equivalent inverse in asm?