CMATH for Borland C/C++ 7.1.3

A useful and comprehensive library for complex-number arithmetics and mathematics

CMATH for Borland C/C++ is a useful and comprehensive library for complex-number arithmetics and mathematics, both in cartesian and in polar coordinates, for C/C++ and Pascal/Delphi compilers. CMATH is available as a stand-alone product. It is also included in the OptiVec package.

All functions may alternatively be called from classic C and Pascal/Delphi with type-specific function names (like cf_sin, cd_exp, pe_sqrt), or from C++ and Delphi with overloaded function names and operators (like sin, exp, sqrt, operator +; operators only in C++). As far as possible, all functions have the same names in the Pascal/Delphi version as in the C/C++ version.

Superior speed, accuracy and safety are achieved through the implementation in Assembly language (as opposed to the compiled or inline code of available complex C++ class libraries). Only for the most simple tasks, alternative inline C++ functions are used in the C++ version.

As far as the scope of CMATH overlaps with the complex class implementations of Visual C++, Borland C++, and Delphi, CMATH is a high-quality replacement for the latter, which are all quite inefficient and inaccurate.

In contrast to the written-down-and-compiled textbook formulas of most other available complex libraries (including those coming with Visual C++ and the Borland compilers), the implementation of CMATH was guided by the following rules:

Without any compromise, top priority is always given to the mathematically correct result, with the accuracy demanded for the respective data type. Especially for complex functions, this necessitates a very thorough treatment of many different situations. To this end, the various cases have to be distinguished with pedantic care. (Textbook formulas do not need to treat these situations separately, as they theoretically assume infinite accuracy of intermediate results; an actual implementation, however, has to work with the limited accuracy given by real-life processors.)

Mathematical functions must be "safe" under all circumstances. They may for no reason simply crash, but have to perform a decent error treatment. This is true even - and perhaps especially - for seemingly nonsense arguments, with the single exception of the non-numbers INF and NAN, which occur themselves only as a result of serious errors in other functions.

By all possible means, greatest execution speed must be attained. (After all, you did not buy your fast computer for nothing!)
The program code has to be as compact as possible. However, in case of conflicts, faster execution speed is always given priority over smaller code size.