nuestro modelo).
También el modelo del autor del PGP tiene diferencias con respecto al nuestro:
1. El modelo de ZIMMERMAN también recoge el signo del entero, cosa que, como ya hemos dejado dicho, no se hace en nuestro modelo.
2. El modelo de ZIMMERMAN tiene un campo que recoge el estado del entero codificado. 3. El tipo de dato está finalmente creado como de tipo puntero.
Una vez hemos mostrado diferentes modelos de codificación de enteros y hemos relacionado sus semejanzas y sus diferencias en relación con nuestro modelo, queremos hacer una aclaración al proceso real que ha seguido nuestro trabajo. A pesar de lo que pueda parecer, por el modo en que hemos presentado nuestro modelo y las listas de diferencias con los otros modelos, la realidad es que el primer paso en la implementación de nuestra librería no fue buscar otras ya implementadas y tomar una definición de entero largo como punto de arranque: definición sobre la que posteriormente cabría hacer modificaciones. Lo que hicimos fue crear de forma intuitiva una primera definición de entero largo y, sobre ella, realizar el diseño e implementación de todas y cada una de las funciones que íbamos necesitando o que creíamos necesarias para una completa definición de todos los operadores de un tipo de dato entero.
Nuestro primer modelo de entero fue muy parecido al de los Cuadros 2 y 3. Era de la forma
typedef unsigned long int * NUMERO;
y por tanto se diferenciaba del modelo de COHEN y de LENSTRA, ya desde su inicio, en que los dígitos eran enteros sin signo, que la base de codificación era 32
2
y que no reservábamos ningún elemento del vector que asociásemos a las variables tipo NUMERO para el signo o para el tamañoUna nueva implementación de entero largo para procesos de factorización 80 del entero codificado.
A medida que avanzamos en la implementación de las distintas funciones fueron llegando las modificaciones sobre nuestro primer modelo. Al terminar todas las implementaciones de las funciones que presentaremos en este Capítulo nuestro modelo había ya quedado en la forma señalada en el Cuadro 4, salvo una diferencia: manteníamos un campo para el signo; campo del que, como ya hemos dicho, pudimos luego prescindir al comprobar su escaso o nulo uso que necesitábamos hacer de él.
El siguiente paso fue ya el de la búsqueda de otras implementaciones. Búsqueda y selección de aquellas que nos parecieran más válidas, según los criterios que ya antes hemos recogido. Se puede pensar que realizamos nuestra tarea en el orden inverso al que hubiera sido lógico en un trabajo como el nuestro. Quizá sea cierto. Pero gracias a este modo de proceder, pudimos comprobar que el proceso de implementación del entero nos había conducido a modelos muy semejantes a los que luego hemos encontrado ya hechos. Quizá se puedan implementar modelos de formato esencialmente diverso a los presentados en estas líneas. Pero quizá podamos pensar que la misma forma de ser de los enteros largos y con la actual arquitectura de los ordenadores de que disponemos, los modelos que se pueden definir apuntan a un formato como el de los presentados aquí.
Cabría pensar que el trabajo de implementar toda la librería es una tarea ya realizada por otras personas de reconocida capacidad. Pero como decíamos al principio de este epígrafe, un tipo de dato no es solo un dominio de valores, o un modelo de representación o codificación de esos valores; un tipo de dato también presupone un conjunto amplio de operadores que hay que definir. Y si queríamos realizar una implementación optimizada a la luz de la interacción del software compilado con el ordenador, era necesario conocer a la perfección cada una de las funciones. No sabemos cuál es, de entre todas las recogidas, la mejor implementación de entero largo. Pero sólo la nuestra ha podido ser sometida a la tarea de optimización. No nos parecía viable pretender modificar, al detalle al que hemos podido llegar en nuestras funciones, las funciones implementadas por otros programadores.
Más adelante, en el Capítulo 7, podremos comprobar cómo las funciones básicas que definen los operadores de este modelo, intervienen en el proceso de factorización una cantidad enorme de veces; y podremos comprobar cómo cualquier mejora en la implementación de cada una de esas funciones, supone una mejora el rendimiento en la ejecución y, por tanto, en la eficiencia de nuestro modelo. Y a la vista de los resultados recogidos en el Capítulo 7 podemos afirmar que nuestro proceso de optimización ofrece buenos resultados.
4.2.2.2. Otras consideraciones sobre nuestro modelo de entero largo.
Hay que determinar el orden de los dígitos (los diferentes elementos unsigned long int) en la memoria. Hemos tenido en cuenta para esta decisión que los ordenadores PC (que usan
Una nueva implementación de entero largo para procesos de factorización 81 microprocesadores Intel y AMD) son little–endian: es decir, que una variable que use más de un
byte para su codificación almacena el byte de menor peso en la dirección más baja de memoria y el byte de mayor peso en la dirección más alta.
En el Cuadro 5 recogemos el orden de los bits en un entero largo de 32 bits (unsigned long int) almacenado en memoria mediante el formato little–endian. Si nuestro número requiere más de un elemento de 4 bytes, la posición lógica a colocar los siguientes bits más allá del bit 31 es a partir del bit 32, que corresponde al bit 0 de un segundo elemento unsigned long int.
Hemos optado por este formato little–endian porque es el que utilizan los ordenadores sobre los que hemos realizado toda nuestra programación. Por tanto tenemos que el valor del campo T en nuestra estructura NUMERO indica la cantidad de elementos unsigned long int empleados para la codificación, pero también señala la posición del elemento más significativo. Y B señala la posición del bit más significativo. Como ya hemos dicho, este sistema de codificación deja muy accesible algunas operaciones: será mayor aquel número cuyo valor del campo B sea mayor. Un número será igual a cero si el campo B, o el campo T, es igual a cero. Un número es igual a uno si el campo B es igual a 1.
Evidentemente nada obliga a utilizar este orden y ambas posibilidades (little–endian vs big–
endian) son igualmente válidas. Además, transformar un número de un formato a otro es tarea
inmediata. Una vez tomada la opción, evidentemente, todas las operaciones se realizarán teniéndola en cuenta. La implementación de la librería FreeLIP también ha tomado el formato
little–endian.