Normally one avoids this by not rounding until the last possible operation. If you post your calculation code, we may be able to spot where the truncation is happening.

SBebtBot! Exactly what I need! LOL
Anyway, here is some code that once in a while rounds.

Thanks

PianoMan

var vAmount as Double
var vBalance as Double
var vNewBalance as Double

vAmount = Amount
If vAmount > 0
{
vBalance = @FormFieldValue("INVOICE", "Balance_Due", 0)
vNewBalance = @TM(vBalance) - @TM(vAmount)
FormFieldValue("INVOICE", "Balance_Due", 0, vNewBalance)
}

I seem to recall that some other programs (Access/VB/Visual?) sometimes rounded differently on Odd/Even numbers for the last digit 5.
The justification was that it was supposed to provide more accuracy with larger groups of numbers.
-----------------------------------------------------------
Another unexpected problem in other languages resulted from calculations  using floating-point numbers.
Example:
Int(3.555 * 100) results in 356., but
Int(4.555 * 100) results in 455 instead of 456.
-----------------------------------------------------

Does Sesame have any specific rules/exceptions like these mentioned from other programs? 
The only limitation I could see was the rounding range was limited from -15 to +15.

Will last digit 1-4 always round down?
Will last digit 5 always round up?
Will last digit 6-9 always round up?

Quote:

Mark,

Thank you for this explanation! I always knew that floating point calculations did this sort of thing. But I don't rememeber anybody ever explaining exactly why, they would just say that floating point is more accurate and non-floating point (fixed-point?) calculations are more precise.

Now I understand what was meant by that statement, as you point out, it "...is to raise accumulated accuracy when rounding a large series of numbers...".

Quote:


Hello Bob,

There are no system settings for rounding. The OS Defaults Mark was referring to are on the first tab of the Regional and Language Options. If you set your System Number Format to have two decimal places, Then a number element in Sesame formatted to "SYSTEM" will display two decimal places, and numbers ending in a 5 or above will be rounded up.

-Ray

Bob,

MyMoneyLE = @Rnd(vMyFinalMoneyValue, 2)

This will solve the rounding issue, plus you don't need to remember to check the OS systems settings on every computer you install your applicaton on, because it will already be in the application.

The only time this won't take care of it, is if someone types $8.885 from the keyboard. But, if that happens, Sesame will show a warning message indicating what it is changing it to.

Edit:
Forgot to mention that @Rnd appears to be following the rule of always rounding a 5 up.

WHOOPS!  

I didn't see Ray's last post. Judging by the timestamps, I was in the process of writing my post.

I just built a small app to test some various things... and Ray is correct.  

After I added @Rnd to one of my apps, I was getting the same exact values as the Q&A DB it was replacing, so I thought I had solved my problem. The problem values I found were $8.885 & $3.235, which were corrected with @Rnd, so I thought this was solved. But, it looks like @Rnd and element formatting are each following different rules for floating-point rounding.

Bottom line:
Mark & Ray have the correct solution. That is, "simply set the OS defaults as needed, and in Sesame specify SYSTEM as the format."

Sorry about the confusion.  

########## EDIT: New bottom line solution ##########

Using the OS settings still allows the raw value to be saved to disk without rounding it to 2 decimal places.  This could present a problem if you were to export the data, or if you were to move the application to a computer that did not have the same OS settings for currency display format. Also, it's that raw non-rounded value that will be used by SBasic for other functions. For example, if you are using that value to build a money-to-words line for a check, it will use the raw data, which may not be the same as is displayed in the money element.

After a lot of frustration with the built-in functions not giving me what I wanted, I wrote my own user-defined function. So far, it has consistantly given me the results I wanted - which is to always round money up when the 3rd digit after the decimal point is a "5".

//########## Begin Custom Rounding Function ##########
Function @cuRnd(Value as double, Places as int) as double

var vNeg as int            //Used to handle Negatives properly
var vStr as string

if Value < 0
      vNeg = -1
else
      vNeg = 1

vStr = @Str(@Abs(Value))

if @Instr(vStr, ".") > 0      //Protects whole numbers when rounding to zero places
      {
      if @Mid(vStr, @Instr(vStr, ".") + Places + 1, 1) >= 5
            vStr = @Str( @TN(vStr) + (1 / @Exp(10, Places)) )
      vStr = @Del(vStr, @Instr(vStr, ".") + Places + 1, 10)
      }

vStr = @Str(@TN(vStr) * vNeg)

Return @TN(vStr)

End Function
//########## End Custom Rounding Function ##########
 

@cuRnd(V, P)
Parameters: V as Double, P as Integer
Returns: Double

Rounds off the value of V to P decimal places. Unlike the regular @Rnd function, the value of P must be a positive number, meaning that it is only designed to round to whole numbers or to tenths, hundredths, thounsandths, etc. - not to the nearest tens, hundreds, etc.