Empower 2 cut off the decimals in a result, not round

[Ralf_Kr]

Hi,

Is it possible in Empower 2 cut off the decimals in a result, not round.
Example: 100.2143 43 automatically cut to 100.21 then rounded to 100.2

Custom Field that?

Thank you very much

Ralf

[tkubowicz]

Hello

Why do you want to cut off? You can round your result (100.2143 ) to one decimal place.

Regards

Tomasz Kubowicz

[Ralf_Kr]

If so set absurdly in the SOP.
That empower problem I have now.
The results to round would have done it!
Perhaps still a solution?
greetings

[Peter Apps]

Since that SOP contradicts every bit of official guidance on significant figures and rounding it should be very simple to change it rather than struggling to make software do it wrong.

Peter

[Ralf_Kr]

another example

100.5 623
100.6 256
100.7 896

Average: 100.6 100.7 with 3 decimal places

greetings

Ralf

[Peter Apps]

If you only have a few numbers it is very easy to find examples when the full and rounded versions differ in mean, or when expressed as % the total is not 100%.

The guidance is clear - decimals must be rounded, not truncated: here is my list of three numbers that demonstrate why;

9.9999
10.000
10.099

become 9.9; 10.0; 10.0 when truncated; 10.0, 10.0 and 10.1 when rounded. The rounded numbers are more accurate.

Peter

[Ralf_Kr]

So I would also make the SOP but is now just how it is.
Perhaps still reports an Empower Crack with a wonderful Custom Field.

Ralf

[Peter Apps]

For 2 decimals; multiply by 100, truncate to the integer, then divide by 100. If Empower won't do it then export to Excel.

Good luck when the auditors came around !

Peter

[DR]

What I would do if I were you: Set precision to the number of decimal places you need reported.

If someone comes around and complains that Empower is doing it "wrong per SOP", that is a good time to explain that it is the SOP that is wrong and should be changed. Empower (and Excel, Chromeleon, OpenLab...) all do it *this* way, which happens to be the mathematically, and compendially correct way to do it.
Then ask "So, shall we mount a campaign to obtain and change the source code so that the agency won't like it, or shall we correct our SOP...which sounds easier to you?"

[lmh]

Actually, Ralf, in your original posting you suggest a hybrid of cutting off all decimal places beyond the second, and then rounding to one decimal place..

Here is your example: "Example: 100.2143 43 automatically cut to 100.21 then rounded to 100.2"

I hope I've understood that correctly. If so, then the SOP is suggesting a step that makes no difference anyway. Rounding to one decimal place should give the same result as truncating to two followed by rounding to one.

I'd second everything that others have written: it is a very bad idea to specify unconventional ways to deal with fractional values. If the way in which you round or truncate values regularly affects your organisation's decisions, then your organisation is also doing something seriously wrong.

A symptom of this is that almost certainly no one will have defined anywhere what they mean by rounding anyway (no one ever does), and yet it varies, even in your desktop software. Excel's "round" function in a worksheet cell, for example, works differently to the "round" function that it uses in user-defined functions (which works like Access's rounding)...

[Ralf_Kr]

Hi,

this was a bad example, see post Wed June 8, 2016 7:21 am, this is better, the results are not equal here.
The SOP can not be changed, the chef is as uncompromising.
I'll cut the results by hand, and finished.

Ralf

[lmh]

OK, you tried! I hope the chief has a good explanation if he's ever audited. I wouldn't like to argue that 2.9 is nearly 2, myself.

[ydna1977]

Hi ,

Try truncation custom field :

ROUND(Amount+0.005,-2)-0.01 where reported result is 2pd