Java bigdecimal entre
¿hay alguna razón en particular por la que tenga que usar BigDecimal para trabajar con estas cantidades de dólares y centavos? ¿no podría simplemente usar enteros y BigIntegers para trabajar con números enteros de centavos en su lugar? entonces no necesitaría redondear nada en absoluto.
Gracias. Debería llamar a setScale(2, BigDecimal.ROUND_HALF_UP) en cada BigDecimal que uso, entonces las comparaciones funcionan correctamente. Supongo que también podría haber utilizado un long y trasladar las cantidades de dólares, incluidos los centavos, a ellos. Sin embargo, entonces tendría que convertir los dobles en largos, así como las cadenas. Como sólo tengo un pequeño número de cálculos, BigDecimal fue el enfoque más rápido. Gracias de nuevo por su solución.
Porcentaje Java bigdecimal
Debido a su inexactitud, los tipos de datos de punto flotante no pueden utilizarse en los cálculos financieros. Por ello, Java proporciona una clase separada llamada BigDecimal para la ejecución de operaciones. BigDecimal reduce las posibilidades de errores de cálculo.
En los números dobles, la clase BigDecimal proporciona funciones aritméticas, de gestión de escala, de redondeo, de comparación, de conversión de formato y de hash. Compensa la complejidad temporal manejando enteros de punto flotante grandes y pequeños con una precisión excepcional.
Mientras que tanto BigInteger como BigDecimal admiten enteros de precisión arbitraria, BigDecimal sólo admite números de precisión arbitraria en coma fija. BigDecimal/BigInteger no es aconsejable si está construyendo una aplicación de baja latencia donde cada microsegundo cuenta.
El error que se produce se debe a que la operación sólo puede realizarse sobre objetos BigDecimal. Nuestro tipo de datos primitivo debe ser convertido en un objeto BigDecimal utilizando el constructor de la clase BigDecimal.
Bigdecimal mod
En primer lugar, en teoría, no tienen un tamaño máximo. Decimos “en teoría”, porque no hay ordenadores con memoria infinita. Y si su programa crea un número mayor que la cantidad de memoria disponible, entonces, el programa no funcionará, por supuesto. Pero estos casos son poco probables.
En primer lugar, para los cálculos con requisitos de precisión extremadamente rigurosos. Por ejemplo, la vida humana puede depender de la precisión de los cálculos de algunos programas (por ejemplo, el software que controla los aviones, los cohetes o los equipos médicos).
Este es otro punto importante. Las clases de números grandes no utilizan los operadores + – * /. En su lugar, proporcionan un conjunto de métodos. Vamos a familiarizarnos con los principales (como siempre, puedes encontrar una lista completa de métodos en la documentación de Oracle: aquí y aquí).
BigDecimal tiene un total de 8 modos de redondeo. ¡Eso es mucho! Pero si realmente necesitas afinar la precisión de tus cálculos, tendrás todo lo que necesitas. Así que, aquí están los 8 modos de redondeo que ofrece BigDecimal:
Java bigdecimal to integer
FWIW, a lo largo de los años ha habido importantes quejas de los usuarios argumentando que Groovy debería traducir == a equals incluso para los tipos Comparables (por ejemplo [GROOVY-3364] ¡El operador == ya no funciona si se implementa Comparable! – ASF JIRA).
IMO == operador debe ser configurable. Para la mayoría de los casos Equals está bien, pero hay clases en las que Equals simplemente no tiene sentido como ==: BigDecimal, Array. Debería haber una forma de alterar el comportamiento por defecto y llamar a compareTo() para BigDecimals, Arrays.compare para Arrays, etc.
No estoy seguro de cómo se prevé esta configurabilidad, especialmente en presencia de clases genéricas. Sería realmente extraño tener == trabajando de manera diferente para t: T en Foo<T> donde T es BigDecimal y para t: BigDecimal.
Por otra parte, considere la posibilidad de añadir algo como el operador nave espacial que comprueba compareTo. Pero la sintaxis sería realmente extraña, y puedo ver los problemas de lexer que se avecinan (¿no es template<X<Y>> en C++ y x: T<U>=m en kotlin ya bastante malo?)
Es muy recomendable, pero no estrictamente necesario que (x.compareTo(y)==0) == (x.equals(y)). En general, cualquier clase que implemente la interfaz Comparable y viole esta condición debe indicar claramente este hecho. El lenguaje recomendado es “Nota: esta clase tiene un ordenamiento natural que es inconsistente con equals”.
