Hello

In my converted panX db many of the fields are dollar amounts with only two decimal places. When I run procedures where these numeric fields are either added, subtracted or multiplied and the results are entered into different text fields i get results that have 16 decimal places. I didn’t have this problem in pan6. Any suggestions. Thank you.

Dave

# Too many decimal places

**Davee**#1

**admin**#2

In Panorama X there are only two types of numbers – integers and floating point values. If your Panorama 6 database had fixed point values, for example 2 digit values for money, those are now converted to floating point, which always has about 16 digits of precision. This also means that you no longer have to worry about underflow and overflow problems, which sometimes silently caused calculation errors in Panorama 6. In Panorama 6 the documentation had a section about how to avoid underflow and overflow errors in calculations – in Panorama X this section was removed because it is no longer necessary.

If you want a number converted to text with less than full precision, use the pattern( function, for example:

```
pattern(value,"#.##")
```

This will convert the number to text with two places after the decimal point.

There is a video that talks about working with numbers in Panorama X.

**KJM**#4

But I think Dave wants to keep those values as numbers in his field, so he can do his calculations. He simply needs to set an **output pattern** (in the field properties) to display the floating point numbers with 2 digits only.

**JohnB**#5

Jim is right. The old, Panorama 6 way of numbers and math being either floating point or 0-4 digits after the decimal point had problems. Old-timers, however, may have gotten used to those problems and not yet have become used to the different problems caused by using only integers or floating point numbers.

Binary floating point math is very powerful, yet has unavoidable limitations because many decimal numbers in their binary representations are irrational like pi in a decimal system. They can’t be represented precisely with any finite number of bits. This can surprise you, eg. Panorama claims “0” doesn’t equal “0” because they differ in their 15th digit. Using the `round(`

function judiciously can help your calculations, and selections based on them, turn out as expected. For currency values, `round(yourValue,0.01)`

is a friend.

**dave**#6

Actually, that should be, many terminating decimals, in their binary representations, will repeat like 1/3 in a decimal system. A number like one tenth for example is 0.1 in decimal, but in binary it is 0.000110011[0011]. The square brackets surround the repeating pattern.

If a number is rational, it will be rational in every system. If it is irrational it will be irrational in every system. Irrational numbers go for ever, without falling into a pattern that repeats forever. Rational numbers will either terminate or repeat. Which one they do depends on the base. In base 3, one third is just 0.1.

**BruceDeB**#7

There are some conventions that deal with money, and I am not certain how well they are handled by Panorama.

There is a fine discussion of the problems that one runs into is here: