Replace sine table with 5th order approximation

[ndsl7109256]

The previous implementation used the pre-calculated fixed-point
arithmetic table for sine values, which added over 2 KiB to the code
size.

To solve this issue, I implemented the 5th order polynomial
approximation for sine, which reduced the code size from 2556 bytes
to 494 bytes (by about 80%) while maintaining acceptable error (RMS
error is 8.866 observed with 0-90 degrees, 0-1024 in fixed-point
representation)

Original code size with sine table.

$ size .libtwin.a/src/trig.c.o
   text	   data	    bss	    dec	    hex	filename
   2556	      0	      0	   2556	    9fc	.libtwin.a/src/trig.c.o

Code size after using 5th order approximation

$ size .libtwin.a/src/trig.c.o
   text	   data	    bss	    dec	    hex	filename
   494	      0	      0	   494	    1ee	.libtwin.a/src/trig.c.o

I initially tried a 3rd order approximation, but the error was slightly large, causing the drawn circle to appear not perfectly round. Below is some analysis.

RMS Error Comparing with Sine table (valued from 0-65536, observed with 0-90 degrees, 0-1024 in fixed-point
representation)

	3rd approximation	5th approximation
RMS	878.000907	8.8665040

ref:
https://www.nullhardware.com/blog/fixed-point-sine-and-cosine-for-embedded-systems/
https://hackmd.io/@rickywu0421/FinalProject#透過-3rd-order-sine-approximation-模擬-RSSI

[jserv]

You can implement a new public function, twin_sincos(twin_angle_t a, twin_fixed_t *sin, twin_fixed_t *cos), to compute both sine and cosine at the same time and store the results in *sin and *cos, as several applications need the sine and cosine of the same angle a. Then, you can replace all occurrences of twin_sin and twin_cos with the shortcut twin_sincos, including the code in the files src/path.c and src/matrix.c.

Reference: https://man7.org/linux/man-pages/man3/sincos.3.html (GNU extension)

[jserv]

glibc implementation of sincos:

• sysdeps/ieee754/flt-32/s_sincosf.h
• sysdeps/ieee754/flt-32/s_sincosf_data.c
• sysdeps/ieee754/flt-32/s_sincosf.c

[jouae]

@ndsl7109256 Hey! You do a great job!

Here is a suggestion make your report getting better.

When mentioning RMS or MSE, be sure to include the number of observations.

[jouae]

In the PR, you wrote about the method used to compare code sizes, third-order and fifth-order approximation tests, and included references. However, in this commit, you did not mention them. Additionally, for the 80%, please add the actual data and the calculation process based on that actual data.

Remember, "writing a good commit" is an ongoing challenge for every engineer, including myself. Commits are written for others to read; they are not just explanations to convince others to accept a PR but also records of references, ways to solve problems, simple comparative data, and the reasons for adopting a particular solution at that time.

Once again, you did a great job, which includes code size comparisons, differences between third-order and fifth-order approximations, and providing data sources. Every piece of data and record is the result of your hard work and should be documented in the commit for future reference to see these contributions.

Thank you.

[jouae]

@ndsl7109256
Please include the number of observations on which the RMS error is based.

[jserv]

Is it possible to calculate tan(x) without divisions?

[ndsl7109256]

I think we could use Taylor series expansion to calculate tan(x) without using division, but as x approaches 90 degrees, the error would become very large. I'm not sure if this is suitable for use in this project.

[jserv]

I think we could use Taylor series expansion to calculate tan(x) without using division, but as x approaches 90 degrees, the error would become very large. I'm not sure if this is suitable for use in this project.

TWIN_FIXED_MAX can be set for $tan(\pi/2)$ while TWIN_FIXED_MIN can be set for $tan(-\pi/2)$.

[ndsl7109256]

Though we could set $tan( \pi /2)$ to TWIN_FIXED_MAX directly. However, we still suffer significant error when angle is closed to $\pi/2$. Should we just neglect the error here?

[jserv]

@jouae, Can you comment this? Can CORDIC algorithm be applied to tan(x)?

[jserv]

I need to spend some time studying the principles of CORDIC.

See https://github.com/Max-Gulda/Cordic-Math/blob/main/lib/cordicMath/src/cordic-math.c#L290-L332

[jouae]

Perhaps we can improve the division about $\frac{x}{y}$

see https://hackmd.io/@sysprog/linux-intdiv

[ndsl7109256]

Perhaps we can improve the division about x y

see https://hackmd.io/@sysprog/linux-intdiv

@jouae Thanks for the follow-up!
The divisor we use (x calculated in CORDIC or cos calculated in current way) varies for different angles. Is it possible to improve by the mentioned techniques?
Could you provide a more detailed explanation of your idea? Thanks!

[jouae]

@ndsl7109256
Sure, leave it to me, dude.

[jserv]

@jouae, Create a new GitHub issue when this pull request is merged.

[jserv]

1. Squash the commits and refine the git commit messages.
2. Don't use markdown syntax in git commit messages. Instead, always use plain English.
3. Append Close #13 at the end of the git commit message.
4. Add comment about CORDIC based tangent function improvement.

[ndsl7109256]

Enhancement: Implement CORDIC algorithm for tan calculation

Currently, the twin_tan function uses division, which may be computationally expensive. A potential improvement would be to implement the CORDIC algorithm for calculating tan. This would avoid the use of the divider and potentially improve performance.

References:
https://github.com/Max-Gulda/Cordic-Math/blob/main/lib/cordicMath/src/cordic-math.c#L290-L332
https://hackmd.io/@sysprog/linux-intdiv

[jserv]

Thank @ndsl7109256 for contributing!