Too many decimal places

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.

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:


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.

This topic is also discussed in this video starting at about the 6 1/2 minute mark.

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.

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.

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.

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:

That is very silly :slight_smile:

This is odd as Pan X seems to ignore the need for onlyh 2 decimals for money! Does anyopne have a formals for me, I’m just too tired and annoyed at so much need for conversion to Pan X. I need a formula that will calculate markup and display on;y 2 decimal spaces in numeric form, NOT text! Presently my formula for the field is a follows, how can I change the formulafill to show only 2 digits, rounded up or down if possible:
Field “Markup”
Select Credit <> 0 and Debit <> 0
FormulaFill zeroblank(100*(Credit-Debit)/Debit)

You don’t do it in the formulafill. You do it in the field properties panel of your Markup field. Set the output pattern to #.## That will cause the numbers to be displayed to 2 decimal places, rounded to the nearest hundredth.

That’s what Kurt was getting at in his post. The field will still be a numeric field. The value that is displayed will be rounded, but the value that is stored there will not.