Trazado $\left(1+\frac{1}{x^n}\right)^{x^n}$ .

Question

Cuando trazo la siguiente función, el gráfico se comporta de forma extraña:

$$f(x) = \left(1+\frac{1}{x^{16}}\right)^{x^{16}}$$

Mientras que $\lim_{x\to +\infty} f(x) = e$ el gráfico comienza a desvanecerse en $x \approx 6$ . ¿Qué ocurre aquí? (trazado en mi viejo y fiable PC de 32 bits.)

Supongo que es por la aproximación informática y la pérdida de dígitos significativos. Así que me puse a calcular la representación binaria para ver si es así. Sin embargo en mis cálculos los valores de $x=8$ debería seguir comportándose bien.

Si la aproximación informática fuera el problema, entonces el trazado de esta función en un pc de 64 bits debería evadir el problema (un poco). He probado los servidores de Wolfram Alpha:

El problema se mantiene para los mismos valores de $x$ .

Preguntas

1. ¿Podría alguien señalar el problema? ¿Qué pasa con la parcela de 32 vs 64 bits?
2. ¿Existe una forma de predecir en qué $x$ -valor la gráfica de la función de abajo empezaría a fallar? $$f_n(x) = \left(1+\frac{1}{x^n}\right)^{x^n}$$

Answer 1

32bit vs. 64bit afecta a los tipos de enteros que se utilizan por defecto, lo que no es de interés aquí. Más bien, los cálculos de punto flotante se hacen (por defecto) con IEEE double tipo. Con este double precisión (mantisa de 53 bits), el error relativo de $(1+\frac1{x^{16}})$ es aproximadamente $2^{-53}$ . Elevación a la $x^{16}$ de la potencia multiplica aproximadamente el error relativo, por lo que es $\frac{8^{16}}{2^{53}}=2^{-5}$ (así que absolutamente $\approx 0.1$ ) para $x=8$ que sí coincide con su parcela. En $x=9$ podemos esperar un error relativo $\frac{9^{16}}{2^{53}}\approx0.2$ también es coherente con su trama. Para $x>10$ tenemos $x^{16}>2^{53}$ Así que $(1+\frac1{x^{16}})\dot=1$ mientras que justo antes de este corte a un $(1+\frac1{x^{16}})$ , tenemos una fase más larga de demasiado grande en el último y único bit, es decir, esencialmente calculamos $(1+\frac2{x^{16}})^{x^{16}}\approx e^2\approx 7.4$ .

Answer 2

Su problema es la precisión finita de la aritmética de punto flotante. Sólo hay tantos números cerca de $1$ que puede ser representado por el formato de punto flotante del ordenador, y cuanto mayor sea su $x$ es, cuanto más diferencia entre $1$ y $1+\frac{1}{x^{16}}$ (que es lo que realmente importa cuando se eleva a una potencia enorme) se perderá por el redondeo del último resultado intermedio.

Para poder realizar cálculos precisos con dichas expresiones, muchos lenguajes de programación proporcionan funciones primitivas para calcular $x\mapsto \log(1+x)$ y $x\mapsto e^x-1$ directamente, sin siempre representando el resultado intermedio $1+x$ y $e^x$ explícitamente.

Para utilizarlo en su caso, tendría que reescribir $$ (1+a)^b = e^{b \log (1+a)}$$ y escribir algo como (por ejemplo, en C, con <math.h> ):

double x16 = pow(x,16);
double result = exp(log1p(1/x16) * x16);

---

No debería esperar ninguna diferencia entre calcular en una máquina de 32 bits o de 64 bits, porque incluso en las máquinas de "32 bits" la precisión habitual de los cálculos en coma flotante es una representación de 64 bits con unos 16 dígitos significativos de precisión.

(Por el contrario, tanto las máquinas de 32 bits como las de 64 bits admiten un formato de punto flotante de 32 bits, pero las operaciones en él no suelen ser más rápidas (en contraste con la aritmética de enteros, donde las operaciones de 64 bits son más lento en máquinas de 32 bits), por lo que en la práctica sólo se utiliza cuando se necesita almacenar tantos números en coma flotante que el tamaño combinado de todos ellos se convierte en una preocupación).

Answer 3

Aquí hay un gráfico utilizando la calculadora (de precisión arbitraria) Pari/GP. Utilicé una precisión de 200 dígitos por defecto en mis cálculos y obtuve este gráfico sin oscilación hasta x=20:

Lo he probado hasta x=256; no hay oscilación. Vea aquí la imagen hasta x=128 (sólo para que se vea el aumento de la izquierda)