PSPNum supports decimal numeric fields of fixed-length. Within this fixed-length, PSPNum maintains an exact numeric value. The opposite of this is floating-point, where complex technical standards and 'degrees of precision' apply to numeric values. Our view is simple - floating point is for scientists, exact decimal numerics are for business. PSPNum is for serious business.

PSPNum requires you to specify the number of digits you want either side of the decimal place via the DigitsBeforeDP and DigitsAfterDP properties. Both these have a maximum value of 50. PSPNum ensures you always have at least one digit i.e. it is impossible to have both DigitsBeforeDP and DigitsAfterDP exactly zero.

When each PSPNum is first created, you get an opportunity to specify the number of digits you require via the PSPNum constructor. Both DigitsBeforeDP and DigitsAfterDP are persistent properties. This means any digit settings you make can be saved for when an application using the PSPNum restarts. After each PSPNum is initialised (from persistent storage if needs be), you can revise the size using the setDigitsBeforeDP() and setDigitsAfterDP() functions. For example you may have a multi-currency application where you want to change an initial setting of 2 decimal places to 0 decimal places if the run-time value is for a currency with no fractions (e.g. Japanese Yen, Italian Lira).

When you change either DigitsBeforeDP or DigitsAfterDP, PSPNum creates an internal number with the new size then assigns the value of the number with the old size to it. Any excess digits in the old number are silently truncated when this happens. That is, there is no rounding or warning/error about digits being dropped either side of the decimal place. If you are concerned about this loss of numeric digits, you need to check the number of digits actually used (using the getValue() function) before executing setDigitsBeforeDP() or setDigitsAfterDP().

Arithmetic operations may attempt to assign a new value to a PSPNum with more digits either side of the decimal place than the PSPNum itself. PSPNum overflow and rounding determines what happens. Overflow also determines what happens when you key too many digits before the decimal place.

There is something else to note about arithmetic operations for PSPNum's. They may involve different DigitsBeforeDP and/or DigitsAfterDP values. For example, A and B in A.multiply(B) may have a different number of decimal places. PSPNum ensures the results are arithmetically correct because PSPNum internal routines use intermediate values large enough for arithmetic accuracy.