Tengo algoritmo/cálculo en Java y prueba de unidad para él. La prueba unitaria espera resultados con cierta precisión/delta. Ahora porté el algoritmo en .NET y me gustaría usar la misma prueba unitaria. Yo trabajo con doble tipo de datos.Biblioteca de punto flotante estricto Matemáticas en .NET
El problema es que Java usa strictfp (64bits) para algunas operaciones en la clase Math. Donde como .NET utiliza FPU/CPU siempre (80 bits). .NET es más preciso y más rápido. Java es más predecible.
Como mi algo es cíclico y reutiliza los resultados de la ronda anterior, el error/diferencia/más precisión se acumula demasiado grande. No confío en la velocidad (para la prueba unitaria). Y me complace utilizar la precisión .NET en producción, pero me gustaría validar la implementación.
Considere esto desde JDK
public final class Math {
public static double atan2(double y, double x) {
return StrictMath.atan2(y, x); // default impl. delegates to StrictMath
}
}
Busco biblioteca o técnica a utilizar estricta FP en .NET.
Comentario preventivo: Entiendo el formato IEEE 754 y el hecho de que el número de coma flotante no es el número o fracción decimal exacta. Sin decimales, sin BigInt o BigNumber. Por favor, no responda de esta manera, gracias.
No entiendo lo que su unidad de prueba está probando si utiliza diferentes implementaciones de coma flotante de matemáticas entre la Unidad de Pruebas y Producción. ¿No corre el riesgo de no detectar un error que solo se manifiesta con la implementación de .NET? –
El algoritmo/matemática es parte de una prueba de integración más grande. Entonces necesito que este componente se comporte exactamente igual. Solo para la prueba debería tener el mismo redondeo (estricto) que Java, que en realidad es menos preciso. –
Puede ser aún peor. Esta discusión sugiere que CLR puede decidir compilar el código para usar 80-bit x87 coma flotante o SSE2 de 64 bits: https://connect.microsoft.com/VisualStudio/feedback/details/276107/provide-access -to-the-floating-point-context –