From Newsgroup: comp.lang.c
On 2026-08-13 08:38, David Brown wrote:
On 12/08/2026 23:49, Lynn McGuire wrote:
[...]
I have found over the years that 200 points seems to be best when
performing a numerical integration of a curve.-a For me, 200 points is
the point where diminishing returns has set in.-a Of course, YMMV.
Your mileage may very much vary.-a The best number of points depends on
many factors, [...]
That's what I'd also expect. (As far as interpolation is concerned.)
[...]
For my own uses, I typically need things like sin functions for motor control and other such applications.-a Tables of perhaps 16 or 32 evenly spaced points, with cubic interpolation, are often fine to get the
accuracy I need in a few clock cycles on a microcontroller.-a (I don't
think I have ever needed a floating point "pow" on a microcontroller.)
For the sine function I recall some ROM analysis of the PC 1401 pocket calculator I did (for fun) in my youth. Between all the hex codes of
the assembler commands I stumbled across irregular appearing data. It
turned out that they were used for the trigonometric functions, and I identified them as CORDIC constants back then. These tables had been, surprisingly - I didn't knew anything about the underlying math back
then - rather small. Now with help of Google what I find interesting
to read about those table sizes, in the binary case, and in case of
that pocket calculator which uses internally a 12-digit BCD encoding.
"The size of a CORDIC (COordinate Rotation DIgital Computer) angle
lookup table equals the number of iterations (n), where each entry
stores an arctangent value \(\arctan(2^{-i})\) matching the system's
bit width. For standard precision targets, n matches the precision
bit length (e.g., 16 entries for 16-bit, 32 entries for 32-bit),
requiring only tens to hundreds of bytes."
(Which matches with your numbers above. But from your brief mention
I'm not sure the approach you did was comparable with or was CORDIC.)
"The Sharp PC-1401 pocket computer relies on the Hitachi SC61860
8-bit CMOS processor running a specialized BCD (Binary Coded Decimal)
math library in its 40 KB internal ROM. To compute trigonometric and
hyperbolic functions with 10 to 12 digits of precision, the ROM uses
a customized BCD-variant of the CORDIC (Coordinate Rotation Digital
Computer) algorithm."
"Unlike standard binary-based CORDIC implementations that shift bits
by \(2^{-i}\), the PC-1401 processor implements a digit-by-digit BCD
CORDIC calculation (\(10^{-i}\) shifts).
Table Depth (Steps): 11 to 12 entry levels (corresponding to shifts
from 10rU# down to 10rU+-|rU# or 10rU+-|-|).
Data Precision: Numbers are processed internally using an 8-byte
(64-bit) BCD floating-point format.
Total Storage Size: The lookup table for the primary rotation angles
(\(\theta_i = \arctan(10^{-i})\)) occupies exactly 88 to 96 bytes
of the 40 KB system ROM."
(Smaller tables with BCD encoding.)
"Why the Table is So Small
Decimal Shifting: By utilizing BCD, the processor does not need a
massive radix conversion table. It multiplies or divides by powers
of 10 simply by shifting 4-bit nibbles across the internal
registers.
Interleaved Functions: The exact same loop structures and angle
tables are shared globally between SIN, COS, TAN, and their inverse
equivalents (ASN, ACS, ATN), saving critical space in the tightly
packed SC613256 ROM chip."
(And speedy BCD-shifts. - Which reminds me the discussion here about
binary shifts in the float representation of 'pow' when using binary
exp/log representations for optimization purposes.)
One "hammer" (a small CORDIC table) for a whole class of functions;
amazing.
Janis
PS: I'm astonished that Google has all that information - after all
that pocket calculator things are just legacy stuff. (Around 1980,
without the Web (or search engines), it had been really a hard job
to find and identify all that information.)
--- Synchronet 3.22a-Linux NewsLink 1.2