| Kriptópolis alojado en |
| Zilos-Veloxia Network |
| Tu mejor defensa: |
| Bufet Almeida |
"Breaking the Bank": Consejos para programadores de aplicaciones financieras
Enviado por admin el 16. Julio 2008 - 19:00.
Breaking the Bank es un interesante documento que reúne consejos básicos muy útiles para los programadores de aplicaciones financieras a la hora de manejar números mediante diversos lenguajes de programación.
En general, el documento persigue obtener la máxima exactitud a la hora de realizar y procesar cálculos numéricos y para ello llama la atención sobre la posibilidad de generar vulnerabilidades, unas muy obvias y otras no tanto, al manejar de forma inocente o descuidada las diversas APIs.
El documento incluye abundantes ejemplos con código fuente de fácil comprensión y desvela los desastres que pueden fácilmente generarse con tan sólo elegir un tipo inadecuado de datos o realizar una conversión desafortunada entre los diferentes tipos.
Interesante para cualquier programador. Imprescindible para aquellos cuyos programas manejen "dineros".
Librerias Propias
Holitas, felicidades por la güev lo primero.
Respecto a los visualizados errores de programación y concepto... no se porque a día de hoy se dan... para un miniprograma de manejo de numeros enormes, en los que el error de un solo bit, mandaban al traste todas las tareas, y se operaban números de hasta 5000 bits... tras miles de pruebas, nunca dio ningun error...
Lo enfoqué en ANSI C, con funciones operadoras (ej: funcion_sumar()), y lo que hacía era en vez de variables normales (int), lo que hacía era operar ARRAYS... a nivel virtual generaba la tabla:
Asi que para sumar 427 con 3, hacía: 7+3=0 y me llevo 1, 2+0+llevada=3,... hasta que al final obtenía un array nuevo con la cantidad exacta. Cuando tenía decimales tb estaba pensado, con una variable INT, que dijera en que posición estaba la COMA en cada numero... ejemplo: 1234567 2 = 12345,67
Espero haberme explicado bien...
¡Considero que los programadores de los bancos, harán algo que igualmente garantice la eficiencia de los movimientos bancarios! El día que demuestren que no es así, viendo que mi dinero desaparece, sacaré lo que quede y al colchon... jejejeje
UN ABRAZO PARA TODOS
Fracciones
Interesante artículo. Donde trabajo hacemos aplicaciones financieras y desde hace tiempo no usamos floats ni nada que se les parezca sino que usamos Fractions (en Smalltalk vienen incluidas en el ambiente por defecto) que además tienen la ventaja de no tener límite en el tamaño de los números (bah!! lo que se banque la memoria de la máquina donde corre :) ).
Es un poco más lento pero hasta ahora nunca tuvimos problemas de redondeo.
Lo que entiendo...
Lo que entiendo del documento, es que estos lenguajes, C# y Java, no son adecuados para software financiero, pues tienen una pobre representación en punto flotante, y otra "peculiar" para BigDecimal... eso de validar los números como string....
Otra cosa es que el mainstream de moda los imponga, pero parece que los core bancarios seguirán muchos años en cobol host.
29 = 28?
Hola a todos,
Me llamo la atencion el snippet donde demuestran (debido a un fallo en el tipo de dato) que 29 = 28, xDDD. Un articulo muy interesante, thx.
Salu2.
Opinar