float64 para almacenar datos de precios: ¿es suficiente la precisión?

Question

Estoy buscando almacenar datos de precios de acciones en una tabla hdf5. El uso será puramente como un archivo histórico, no como fuente de datos del día a día.

Opciones

1. Una opción sería almacenar el significante de base10 y el exponente por separado como, por ejemplo, uint64 y uint8. La desventaja es que es bastante incómodo de manejar, especialmente porque los int no vienen de fábrica con el manejo de NaN para los valores perdidos.
2. La otra opción sería utilizar float64 que es más fácil de manejar y tiene soporte NaN incorporado.

Mi pregunta: ¿Tiene float64 suficiente precisión para almacenar datos de precios? ¿Cuál es la experiencia del número de dígitos significativos necesarios para un archivo de precios?

Nota: float64 parece tener 15-17 "dígitos decimales significativos" de precisión. No estoy seguro de si esto significa "dígitos significativos" o si sólo se refiere a los dígitos decimales.

Answer 1

Como antecedentes, Precisión en coma flotante es una forma de almacenar los números de manera que la precisión sea relativa al dígito mayor. Por ejemplo, el número $0.00123$ almacenado en precisión fija necesita 6 dígitos de precisión (3 ceros y los 3 números distintos de cero). Sin embargo, este mismo número almacenado como precisión de punto flotante $1.23 \cdot 10^{-3}$ sólo necesita 3 dígitos decimales significativos para almacenar. La coma flotante es generalmente una forma más eficiente de almacenar números que tienen muchos órdenes de magnitud pero lo más importante es que se almacenan en una forma en la que el ordenador puede hacer cálculos básicos eficientes como la multiplicación y en su caso es mucho más fácil de trabajar que la opción 1.

Incluso los mercados más profundos (tesoros, divisas) sólo necesitan 6-7 dígitos de precisión flotante para almacenar los datos de los precios. Hay algunos limitaciones importantes lo que significa que los precios almacenados no siempre serán exactos, sino tal vez aproximados al decimosexto o decimoséptimo dígito. Si los precios se utilizan en los cálculos posteriores (al fin y al cabo, estamos hablando de finanzas cuantitativas), sería chocante que para números con 6-7 dígitos de precisión el redondeo a la 16ª/17ª cifra importara en absoluto. En el caso de que esta aproximación importe, se puede considerar la opción 3, que es almacenamiento de punto fijo .

Answer 2

Como punto de vista práctico: teniendo hábitos desde el tiempo de float32-by-default, diseñé mi db con tipo Numeric (aka Decimal, es decir, de precisión fija). En este caso, era importante. En la mayoría de los casos, tomé un máximo de 8 dígitos de precisión.

Pero ahora con float64 + Numpy (en el que se basa Pandas) no maneja Decimal sino float64, estoy convirtiendo mi esquema db a float64 (es decir, doble en postgresql). Pasar de float64 (para el procesamiento de Numpy) a Decimal (para el almacenamiento) es demasiado doloroso...

Siendo también operador de mercado, apenas veo valor añadido por encima de los 10 dígitos, siendo los mercados bid/ask lo que son.

Answer 3

En mi caso, depende realmente de si se utiliza algún tipo de software. Suelo obtener mis factores de descuento con una precisión de 15 decimales. Así que siempre estoy almacenando al menos 15 dígitos para DF, y los rendimientos de hasta 7-8 como rhaskett dijo.

Para la renta variable, supongo que es más o menos lo mismo que para los rendimientos, o incluso menos. No obstante, almaceno cualquier rendimiento, precio o ratio con una precisión de 7-8 dígitos.