I am trying to write a scientific calculator for a very small microcontroller with no floating point unit. If the standard c math libraries were included the compiled code would be too large to fit on the device. Float arithmetic is small, but special functions ($\sin,\cos,\tan,\arctan,\exp,\ln,a^b$) are not. This is due to the library's use of lookup tables for correct floating point rounding and to speed things up.
To reduce code size at the expense of runtime speed, one could instead characterize the functions in terms of their series expansions or as differential equations, then approximate a solution using primitive manipulations (say, basic arithmetic).
Taylor series are not great:
- Terms might shrink slowly enough that too much error accumulates before the series tail becomes negligible. For example if the terms of $\exp$ are computed naively: $$x^n/n!=(x\cdot x \cdot \dots \cdot x)/(1\cdot 2 \cdot \dots \cdot n),$$ then when $x>0$ and $n$ is large each term will incur a lot of precision error. But many such terms must be evaluated to yield a precise result.
Differential equations might be better but I am unfamiliar with numerical methods for evaluating them.
Scientific calculators have been around for a long time on devices with even worse functionality than a modern cheap micrcontroller. What were they doing (what can be done) to get around this?
Well, there are hundreds of algorithms that exist to do this sort of thing. For example, the cordic algorithm is used to solve for trigonometric functions, and can also be used to get exponentials (using complex numbers). There is a long history of "upgrading" the technique as the trade off between memory, accuracy and time improved.
For example, you may be aware of using newtons method to approximate square roots, or maybe you've seen the now famous fast inverse square root method that was used in doom, to allow it to deliver the graphics that it did at a time when it was thought nearly impossible.
A good starting place would be here, there are lots of numerical methods that you could learn, and depending on the algorithm you want to choose, you can trade off computational time for memory footprint or accuracy as you see fit.
Hope this helps!