rounding issue?

[wonderful_Fountain157F]

maybe it's me, but are:

#decimalformat(70.625)#
#decimalformat(70.725)#

supposed to give two different rounding results?

[ilssac]

DecimalFormat

Converts a number to a decimal-formatted string.

A number as a string formatted with two decimal places and a thousands separator.

So yes, I would expect those two function calls should output "70.63" and "70.73" respectively.  NOTE the "two decimal places" part of the description

[wonderful_Fountain157F]

sorry, that's not what i meant.

i would think it should be 70.63 and 70.73, but it's not, it comes back with 70.63 and 70.72

i've duplicated on both CF8 and CF9

[Adam Cameron.]

What's more interesting is this code:

<cfset lOriginals = "70.625,70.725">

Original:<br />
<cfoutput>
decimalFormat(70.625): #decimalFormat(70.625)#<br />
decimalFormat(70.725): #decimalFormat(70.725)#<br />
<hr />
Looped:<br />
<cfloop index="n" from="70.625" to="70.725" step="0.1">
    decimalFormat(#n#): #decimalFormat(n)#<cfif listFind(lOriginals, n)>*</cfif><br />
</cfloop>
<hr />
Longer Looped:<br />
<cfloop index="n" from="70.025" to="71.025" step="0.1">
    decimalFormat(#n#): #decimalFormat(n)#<cfif listFind(lOriginals, n)>*</cfif><br />
</cfloop>
<hr />
List Loop:<br />
<cfset lNumbers="70.025,70.125,70.225,70.325,70.425,70.525,70.625,70.725,70.825,70.925,71.025">
<cfloop index="n" list="#lNumbers#">
    decimalFormat(#n#): #decimalFormat(n)#<cfif listFind(lOriginals, n)>*</cfif><br />
</cfloop>
</cfoutput>

Output:

Original:
decimalFormat(70.625): 70.63
decimalFormat(70.725): 70.72

---

Looped:

decimalFormat(70.625): 70.63*

decimalFormat(70.725): 70.72*

---

Longer Looped:

decimalFormat(70.025): 70.03

decimalFormat(70.125): 70.13

decimalFormat(70.225): 70.22

decimalFormat(70.325): 70.32

decimalFormat(70.425): 70.42

decimalFormat(70.525): 70.52

decimalFormat(70.625): 70.62*

decimalFormat(70.725): 70.72*

decimalFormat(70.825): 70.82

decimalFormat(70.925): 70.92

decimalFormat(71.025): 71.02

---

List Loop:
decimalFormat(70.025): 70.03
decimalFormat(70.125): 70.13
decimalFormat(70.225): 70.22
decimalFormat(70.325): 70.33
decimalFormat(70.425): 70.43
decimalFormat(70.525): 70.53
decimalFormat(70.625): 70.63*
decimalFormat(70.725): 70.72*
decimalFormat(70.825): 70.83
decimalFormat(70.925): 70.93
decimalFormat(71.025): 71.03

I did the list version of the loop because I was concerned the differences in the long loop was due to a creeping floating point inaccuracy.

Initially I was going to say it's something to do with the rounding scheme Java uses (http://download-llnw.oracle.com/javase/6/docs/api/java/math/RoundingMode.html

But looking @ that output... I think there's a bug here as I cannot see what's going on.

It's interesting, also, to see the differences in results when using dollarFormat() instead.

Adam Lehman, you're monitoring these forums... any insight?

--

Adam

[wonderful_Fountain157F]

yes, I can't see it as anything else but a bug, and with those results, there isn't even any discernable pattern to it.

[hemant_k1]

Did you check precisionEvaluate? Would it help here?

[Adam Cameron.]

Did you check precisionEvaluate? Would it help here?

Dunno.  In what way are you suggesting to use it?

--

Adam

[BKBK]

I evaluated decimalFormat() for all 1000 decimals of the form

n.m25

where m is any of the digits 0, 1, 2, ..., 9 and n is any of the numbers 1, 2, 3, ..., 100. I am on CF 9.0.1.

In every case, Coldfusion rounded the result to 2 decimal places as expected. In 923 cases, decimalFormat rounded the number up, ending in the digit 3, as expected. However, in the remaining 77 cases, Coldfusion rounded down, ending in the digit 2.

You will find the 77 "bad" cases below. I'll illustrate using the sixth row as example. When you evaluate decimalFormat(x) successively for x=1.525, 2.525, ..., 99.525, 100.525, you will find that the result is rounded up, except 16.52, 17.52, 18.52 and 19.52.

Expression, for n = 1,2,3,...100 _________________________	Coldfusion rounded down decimalFormat(x) for n = ... _____________________________________________________
x = n + 0.025	1, 16, 17, 18, 19, 20
x = n + 0.125
x = n + 0.225	4, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80,  81
x = n + 0.325	8, 9
x = n + 0.425	2, 32, 33, 34, 35, 36, 37, 38, 39, 40
x = n + 0.525	16, 17, 18, 19
x = n + 0.625
x = n + 0.725	4, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80,  81
x = n + 0.825	8, 9
x = n + 0.925	32, 33, 34, 35, 36, 37, 38, 39, 40

You can immediately see that there is a method to the madness. There is a mysterious cycle of fives. Thus, the "bad" integers in row 1 are similar to those in row 6(=5+1), the bad integers in row 3 are similar to those in row 8(=5+3), and so on. There were no bad results for row 2 and for row 7(=5+2). As they say, there is order in chaos.

[BKBK]

This is a worrisome bug. You can use the 'bad' values in my table above to reproduce similar bugs in the function round(). I'll use the values from the sixth row to illustrate the boogy bugginess:

<cfoutput>
round(100*16.525)= #round(100*16.525)#<br>
round(100*17.525)= #round(100*17.525)#<br>
round(100*18.525)= #round(100*18.525)#<br>
round(100*19.525)= #round(100*19.525)#<br>
</cfoutput>

[wonderful_Fountain157F]

so what is to be done then? does adobe monitor these forums?

[Dave Watts]

Yes, they do, but you should submit bugs here:

https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[wonderful_Fountain157F]

yes, i did that, i'll keep everyone updated when they respond

[Dave Watts]

As a rule, I don't think Adobe responds to bug submissions directly. They either incorporate changes into future releases, or they don't. If you need a direct response, and you have a clear bug of some severity, you need to follow that up through Adobe support.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

[hemant_k1]

Please log bugs using public bugtracker -

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html

The wishform submission is received via mail and someone needs to go back to it and log a bug in the bugtracker.

Using public bugtracker with above link is a preferred way. I have gone ahead and logged this bug -

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=84731

Feel free to add your vote to the bug.

[Adam Cameron.]

Using public bugtracker with above link is a preferred way. I have gone ahead and logged this bug -

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#b ugId=84731

Feel free to add your vote to the bug.

Voted.

--

Adam

[yui8979]

Hi, I would like to vote this bug up but can't seem to locate it with that URL anymore. Does anyone know if this is going to be fixed  or if a new bug ticket needs to be logged for this?

[Adam Cameron.]

It's https://bugbase.adobe.com/index.cfm?event=bug&id=3042528.

--

Adam

[Adam Cameron.]

I think you might be seeing a floating point inaccuracy here.

See this code:

<cfoutput>
round(100*16.525)= #round(100*16.525)#<br />
round(100*17.525)= #round(100*17.525)#<br />
round(100*18.525)= #round(100*18.525)#<br />
round(100*19.525)= #round(100*19.525)#<br />
<hr />
round(1652.5)= #round(1652.5)#<br />
round(1752.5)= #round(1752.5)#<br />
round(1852.5)= #round(1852.5)#<br />
round(1952.5)= #round(1952.5)#<br />
</cfoutput>

Results in:

round(100*16.525)= 1652
round(100*17.525)= 1752
round(100*18.525)= 1852
round(100*19.525)= 1952

---

round(1652.5)= 1653

round(1752.5)= 1753

round(1852.5)= 1853

round(1952.5)= 1953

Neat huh?

--

Adam

[BKBK]

round(1652.5)= 1653

...

Neat huh?

Yeah. I was aware of that. In fact, that is why I posted, whence my following point:

I think you might be seeing a floating point inaccuracy here.

See this code:

<cfoutput>
round(100*16.525)= #round(100*16.525)#
...
</cfoutput>

Results in:

round(100*16.525)= 1652
...

There is a simple argument to demonstrate it isn't a case of floating-point inaccuracy.  First, suppose for the moment it was. It would mean that, in evaluating round(100*16.525), Coldfusion rounded the number 16.525 down by some small margin, say, e=0.000001, and processed  round(1652.4999). The result would then be 1652.

By the same token, round(100*15,525) and round(100*20.525)  should produce, respectively, 1552 and 2052. They don't!  Instead, they produce 1553 and 2053, as expected. Run the following, and see how the first and last expressions stand out.

<cfoutput>
round(100*15.525)= #round(100*15.525)#<br>
round(100*16.525)= #round(100*16.525)#<br>
round(100*17.525)= #round(100*17.525)#<br>
round(100*18.525)= #round(100*18.525)#<br>
round(100*19.525)= #round(100*19.525)#<br>
round(100*20.525)= #round(100*20.525)#
</cfoutput>

The result round(100*16.525) shouldn't differ from round(1652.5). This  certainly isn't a floating-point inaccuracy. It is the wrong result,  hence a bee-you-gee!