math - Función ColdFusion Round
rounding (1)
No es la precisión de los números decimales, sino cómo se almacenan los flotantes subyacentes en Java. Esto demuestra:
<cfoutput>
<cfloop array="#[0.275,0.285,0.295]#" index="s">
#s.getClass().getName()#
<cfset f1 = s + 0>
#f1.getClass().getName()#
#f1.toString()#
<cfset f2 = f1*100>
#f2.toString()#
#round(f2)#<br>
</cfloop>
</cfoutput>
Salida:
java.lang.String java.lang.Double 0.275 27.500000000000004 28
java.lang.String java.lang.Doble 0.285 28.499999999999996 28
java.lang.String java.lang.Double 0.295 29.5 30
Solo puedo suponer que debajo del capó CF se usa una mejor precisión cuando se convierte de un hilo a un flotador cuando se realiza <cfset f1 = s + 0> ya que no hay un redondeo peligroso allí. Sin embargo, después de haber realizado el paso de multiplicación estamos obteniendo un error de precisión. 28.5 termina siendo apenas 28.5, por lo que redondea a 28 no 29. Es solo un problema de aritmética de fracción binaria.
Por cierto, no hay nada especial acerca de 0.285. Muchos números se efectúan de manera similar (eche un vistazo al rango de 0.005 a 5.05). Acabas de elegir un grupo que no son (aparte de 0.285).
Hoy encuentro un comportamiento inesperado o falta de conocimiento con ColdFusion 9,10,11 Round function here is my scenario
Ronda (28.5) ---> resultado es 29 esperado
Redondo (0.285 * 100) ---> el resultado es 28 no esperado
Round (precisionEvaluate (0.285 * 100)) ---> result es 29 usando precisionEvaluate!
Redondear (Evaluar (0.285 * 100)) ---> resultado es 29 usando Evaluar!
Este no es un decimal grande, ¿por qué necesitaría usar precisionEvaluar o Evaluar en un número?
En una investigación más profunda, encontré un comportamiento más interesante
El resultado redondo (0.285 * 100) es 28 - ¿Por qué? ¡Estoy esperando 29--!
El resultado redondo (0.295 * 100) es 30 ---- ¡Correcto!
El resultado redondo (0.275 * 100) es 28 ---- ¡Correcto!
El resultado redondo (0.185 * 100) es 19 ---- ¡Correcto!
El resultado redondo (0,385 * 100) es 39 ---- ¡Correcto!