Mark,

I have some elements formatted for money that get their values from programming. Most of the time the value handed to the money element has more than 2 digits after the decimal.

Based on a previous discussion in the "MONEY VALUES ROUNDING" thread, I stopped using @Rnd because of it's unpredictable floating-point method of rounding money values. I changed over to using the OS method that you suggested which displays money predictably on the form.

The problem is the money fields are actually storing the values internally with 6 digits after the decimal point without rounding (which can be seen in Table View). This brings us back to using @Rnd (and it's unpredictable results) when getting a value from a money element.

Shouldn't money fields be storing data with only 2 decimal places, or at least storing the rounded value?

An example of when this is a problem would be when converting dollar amounts to words. Using the code in the latest programming guide on page 249, entering $1.3077 in the money element will produce "77/100" for the cents portion in the words element.

Quote:
I think that you mean converted into an integer TYPE?

So, if a caluculation (vCalc) ends up as 1.3077, converting to an integer would result in 1. 

But having another variable, var vResult as Int, and doing vResult = vCalc we would end up with correct number. 
Now we would format vResult, is that correct?

Mark,

So how can I read the final displayed value that appears on the screen (required for an accurate money to words conversion)? Or is that not possible, and I should take my chances with letting @Rnd trim the value before it is assigned to the money element so that it is stored as just 2 decimal places?

Thanks Mark.

I do want to use table view, so I guess I will need to go back to using @Rnd.

Ohhh! I thought it was using the same floating-point method. That will solve my problem.

THANKS!

We're considering doing so, but the issues are non-trivial.

Many, if not all, of the operating system functions are subject to rounding errors. A rewrite would involve bypassing the operating system functions. Doing it "just like Q&A" (which I assume is what you are looking for) is one method, but it doesn't fix the inherent inaccuracy. It simply changes it to a different brand of inaccuracy. Is the Q&A style inaccuracy "better" simply because it can be predicted? Maybe, maybe not.

It's really a question of in what way do we want to be inaccurate? The predictable way, or the way implemented by a standards organization who put a lot of thought into the effect of such unavoidable inaccuracy over the long run of repeated calculations? Do we want one record to round completely predicatably, or do we want 10000 records to round in a way that evens out the inaccuracy over the whole of the database?

We're looking into the possibilities.

Erika,

I was only looking to have MONEY fields round up if the 3rd decimal place digit is a "5", not all calculations.

Anyway, I was composing my post when you posted your last one. I think I have found the perfect solution for me. I can use the standard @Rnd where appropriate, and I can use my custom @cuRnd just before sending a value to a money element. I'm happy with that. 

Good job, Carl. 

That's one of the nice things about SBasic. While we (as product developers) have to play by rules that meet generalized requirements, the tools provided by SBasic allow you develop solutions for yourself that work for your specific requirements. Thanks for sharing this with others who may want the same behavior.

You might consider posting this to the Programming  Examples board and/or submitting it to Inside Sesame as a Tip.

Also, may I suggest redoing it slightly as something like shown below.  It's untested as I am not at a computer with Sesame, so you probably want to check it out yourself. The changes are:
1. The return type of the Function is declared, so it does not accidentally get forced to an Integer.
2. A separate variable is used to return, rather than taking over an argument. The results of returning a passed in argument can be unpredicatable.

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

var Neg as int //Used to handle Negatives properly
var vRet as Double

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

vRet = @Abs(Value)

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

vRet = vRet * Neg

Return vRet

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

BTW, this code repeatedly treats a number as a String without explicilty converting it first, which means that SBasic is converting it back and forth several times as you go, so you may want to keep an eye on this for anomalies caused by the repeated type conversions.

Just my $0.019999 cents.