If you're developing numerical code on a CommonPoint platform and you'd like to port to other environments, consider writing to the FPCE specification. It is not much different from programming for compatibility across CommonPoint systems:
- Follow the advice in "Strategies for portability across CommonPoint platforms" on page 253, except where it regards the headers
Numerics.h
, FPEnvironment.h
, RandomNumber.h
, IntegerMath.h
, and PrimitiveTypes.h
.
- Use numerical functions from
fp.h
whenever possible. The sine function is spelled sin not Sin and the inverse tangent is atan not ArcTan, for example. Despite cosmetic differences, the functions are computationally identical on CommonPoint platforms.
- For CommonPoint capabilities beyond FPCE, such as the functions Compound and Annuity, use the definition from
Numerics.h
for the CommonPoint implementation and build a substitute implementation for other environments. See "Financial functions" on page 251, the specification of Annuity on page 262, and the specification of Compound on page 263.
- If you assume IEEE compatibility, use the environment functions and types from
fenv.h
; the class structure of FPEnvironment.h
is different from the functional form of fenv.h
.
NOTE
A platform need not be IEEE-compatible to be FPCE-compliant.
- Isolate hexadecimal floating constants in one or more header files in the event you should need to express them in decimal form. You may have to choose your decimal values carefully to obtain the desired floating-point values; although the I/O libraries on most platforms do conform to at least the IEEE standards' specification for binary-decimal conversion, the conversion routines in some compilers don't.
- Don't assume that the elementary functions are as accurate as the CommonPoint implementation. But you should assume that they're monotonic where appropriate, that they remain within their mathematical range, and that they satisfy the usual mathematical identities to within roundoff.
- Avoid dependence on the byte order of numbers in memory. The stream operators for I/O won't be available to insulate your application from byte order, so you'll have to deal with the problem directly when you transfer data between platforms with different byte orders. The problem applies to all data, not just floating-point values.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.
Generated with WebMaker