2010-10-01 10 views
25

Tengo curiosidad acerca de la existencia de normas de "redondeo" cuando se trata del cálculo de datos financieros. Mi idea inicial es realizar el redondeo solo cuando los datos se presentan al usuario (presentación capa).Estándares de redondeo - Cálculos financieros

Si "redondeado" datos se utilizan para otros cálculos, debe ser utilizar el "redondeado" figura o la cifra "en bruto"? ¿alguien tiene algún consejo?

Tenga en cuenta que yo sepa de diferentes métodos de redondeo, es decir, redondeo bancario, etc.

+3

Referencia esencial: http://en.wikipedia.org/wiki/Office_Space – Skilldrick

+0

Tengo este vago recuerdo de algunos estándares de alguien pidiendo que los cálculos se hagan en mils (es decir, $ 0.001 o 1./10 de un centavo).Pero desea hablar con un contador que conozca su jurisdicción particular antes de implementar cualquier cosa de la que usted o sus empleadores puedan ser responsables. Definitivamente uno para CPA Overflow. – dmckee

Respuesta

11

La primera y más importante regla: use un decimal data type, nunca los tipos binarios de coma flotante.

Cuando se debe realizar exactamente el redondeo, las reglamentaciones obligan a hacerlo, como la conversión entre Euro and national currencies que reemplazó.

Si no existen tales reglas, haría todos los cálculos con alta precisión y redondas solo para la presentación, es decir, no usaría valores redondeados para realizar más cálculos. Esto debería producir la mejor precisión global.

+1

La flotación binaria sería mejor que la decimal con muy poca precisión. $ 100⅔ está mejor representado en la base 2 que "100.66666666666 ?????" que en la base 10 como "100.67". Pero con suficiente precisión decimal, estoy de acuerdo en que un tipo de datos decimales suele ser mejor. –

+5

@Joe: No, 100.67 casi siempre sería mejor porque es lo que la gente espera - y, más importante, usar un tipo decimal garantiza que 100.01 + 100.07 = 100.08 en lugar de 200.07999999999998 –

+2

El tiempo para producir lo que la gente espera es en tiempo de visualización, y cuando se realiza el redondeo allí (por ejemplo, '% 0.2f'), las personas verán lo que esperan. si está haciendo cálculos intermedios, creo que es inapropiado truncar/redondear a solo 2 dígitos de precisión. (Por supuesto, esto depende del cálculo en cuestión. El cálculo del interés diario redondeado a 2 lugares podría agregar 0.00 a la cuenta todos los días. Pero la factura del cliente no necesita 15 lugares de precisión.) –

0

Considere el uso de enteros escalados.

En otras palabras, almacene números enteros de centavos en lugar de números fraccionarios de dólares.

+7

No, eso solo elimina el problema en dos puntos decimales. ¿Qué haces cuando es momento de agregar 5% a $ 1.23? – Doradus

9

Acabo de preguntarle a un programador de mainframe de greybeard en la compañía de software financiera para la que trabajo, y me dijo que no existe un estándar conocido y que depende de la práctica del programador.

Si bien los estadísticos conocen el problema del redondeo desde al menos 1906, es difícil encontrar un estándar financiero que lo respalde.

De acuerdo con this sit e, el "Informe de la Comisión Europea The Introduction of the Euro and the Rounding of Currency Amounts sugiere que anteriormente no había un enfoque estándar para el redondeo en la banca".

En general, utilice un modo de redondeo simétrico sin importar en qué base esté trabajando (base-2 o base-10).

Esto evitará sesgos sistemáticos durante los cálculos.

Dicho modo es Round-Half-To-Even, también conocido como "bankers rounding".

Utilice herramientas de lenguaje que le permitan especificar la explicidad del contexto numérico, incluidos los modos de redondeo y truncamiento. Por ejemplo, el módulo decimal de Python. Las suposiciones implícitas hechas por la biblioteca C pueden no ser apropiadas para sus cálculos.

http://en.wikipedia.org/wiki/Rounding#Rounding_to_integer

+0

El estándar Euro que vinculó exige que la mitad se redondee hacia arriba (lo que sea que eso signifique) lo que parece prohibir el redondeo imparcial. – Doradus

3

Ive no se ve la existencia de "un estándar para gobernarlos a todos" - hay cualquier cantidad de normas de redondeo (como se ha referenciado), y parece que entran en juego basado en la industria/código de cliente/moneda (http://en.wikipedia.org/wiki/ISO_4217) - dado que no todos usan 2 lugares después del decimal, el problema se vuelve aún más complicado. Al final del día, su cliente necesita especificar las reglas que quiere implementar ...