🚀 go-pugleaf

Saludos, Juan Pablo.

El 20 Jun 2001 14:24:21 GMT nos contabas:


>> alog(5553023288523357132.21137434038486695936) =
>> alog(0.21137434038486695936) * alog(5553023288523357132) = 
>> 1.62695050249084300164 * 10^5553023288523357132 
>>
>Trabajando en base 10 se pierde precisi�n al logaritmar. El n�mero de
>arriba es m�ltiplo de 10, mientras que 2^(2^64) desde luego que no lo es.

No es esa la cuesti�n. Si lees con atenci�n el resultado que yo daba, lo que
dice es que se trata de un n�mero de 5.553.023.288.523.357.132 d�gitos
decimales (*), de los que se dan los 21 m�s significativos (aunque yo
desechar�a los, por ejemplo, 3 �ltimos porque probablemente incluyan errores
en el c�lculo realizado por bc).

>M�s exacto quedar�a:
>2^18446744073709551616
>�
>10^(4*10^F) = 10^(4000.0000.0000.0000) en hexadecimal.

Ya s� que es exacto, pero no me hago una idea de cu�nto es eso.

>En cualquier caso, la memoria necesaria para almacenar ese n�mero se va
>al orden de los miles de petabytes. El �nico modo que se me ocurre de
>trabajar con esos monstru�tos es con una arquitectura de flujo de datos
>que fuera desechando cifras (ceros en hexadecimal, salvo un uno en la posici�n
>m�s significativa) por un lado conforme le fueran entrando por el otro.

A�n as�, me parece dificilmente realizable por dos motivos:

1- Si consiguiera un m�todo que me permitiera obtener una cifra por ciclo de
reloj y estuviera trabajando a 1 THz, tardar�a 5.553.024 segundos en hallar
el resultado, esto es, algo m�s de dos meses (m�s, por tanto, de una semana).

2- La longitud del resultado: si tuviera los d�gitos separados 2 mm entre s�,
ser�a de 2.776.511.644.261 km, o sea, 107 d�as-luz: mucho m�s de la
distancia que separa la Tierra del Sol.



(*) escrito como entero decimal, que es la forma en la que la mayor parte de
la gente piensa los n�meros: poca gente te entender� si le dices que estamos
a 14 de Junio de 7D1.