Archivo de la categoría ‘Programación’

IEEE754

Martes, 19 de agosto de 2008

Unos de los puntos mas importantes en la evolución de los compiladores fue la coma flotante, los compiladores de la época de apple I, ibm PC, etc, no resolvía directamente este problema, por lo que obligaban a los programadores a implementar soluciones para el calculo de decimales.

Este fue un punto de controversia entre apple y microsoft, quien de los dos fue el primero en desarrollar un compilador que soportase la coma flotante.

Como funciona

Un número entero se almacena en memoria como un dato cualquiera, salvando las distancias del famoso litlle o big endian, de intel, un numero se descompone en bytes que es la unidad mínima de almacenamiento, de esta forma:

3000 se almacena como => (3000/256), (3000 % 256)

en little endian se almacenaría así:

3000 se almacena como => (3000%256), (3000/256)

En un inicio el microprocesador no tenia funcionaes especificas para cálculos en coma flotante, esto obligo a desarrollar una unidad llamada FPU, asi que este elemento unido a los que ya había, producía un entorno de formatos caóticos para un modelo que debería ser fundamente en el calculo informático, así que la IEEE, dio un golpe en la mesa y presento el estandar IEEE754, en el que el numero en coma flotante se almacena como un formato compuesto de signo, exponente y mantisa en un formato de 32 bits.

El formato IEE754

El formato IEEE754 utiliza notación exponencial en la forma Número = Mantisa * BaseExponente, con la base binaria implícita. Se reserva un bit para el signo. El exponente se codifica en representación sesgada o en exceso.

La mantisa se almacena generalmente en posición normalizada con el primer 1 implícito, es decir la coma fraccionaria va a la derecha de este 1. Se reserva 1 bit para el signo 8 bits para el exponente y 23 para la mantisa.

Caso práctico

Pondremos un ejemplo, vamos a codificar un numero con coma flotante, p.e. 17,5, asi que lo primero es hayar los 3 elementos; signo, mantisa y exponente;

Obtener el Signo

El signo es facil es posititvo luego sera =>0 (si fuese negativo sera 1)

Obtener la Mantisa

La mantisa codificamos la parte entera 10001, y la parte decimal en este caso 1, por lo tanto el numero en binario quedara asi; 10001.1

la norma indica que el punto debe ir a la derecha del primer 1, entonces… esto queda 1,00011×2^4, asi que ya tenemos la mantisa (que es todo lo que esta a la derecha del punto)

…y el Exponente

y el exponente, 4 codificado sera 100, otra cosa que indica la norma es que los exponentes empiezan en 127, por lo tanto 4 sera 127+4 = 131, en binario= 100000011

Resultando

Por lo tanto quedara codificado asi;

signo = 0 [1 bit]

exponente= 100000011 [8 bits]

mantisa= 00011000000000000000000 [23 bits]

Otro ejemplo

Otro ejemplo un poco mas complicado: -118,625,

El signo

codificamos el signo: [-]=> 1

La Mantisa

Codificamos la mantisa 118 [1110110] y la parte decimal 0,625[101] asi que esto queda 1110110,101, como la norma dice lo del punto después del primer 1, seria 1,110110101×2^6

El Exponente

Para el exponente 0 es 127 luego para 6 = 127+6 [10000101]

Resultado

signo = 1 (por ser -)

exponente = 10000101

mantisa = 1101101010000000000000

Problemas de precisión

Esto es la teoría y esta muy bien, pero intenta codificar números tan raros como 108,65×0,3, el resultado es que no tienes mantisa suficiente para codificar esto, se requieren mantisas del orden de 68 bits, por lo que en una mantisa de 23, no daría, a esto hay que sumarle los bits que se necesitan para la parte entera.

Así que un trivialidad como decir cual es el resultado de restar 0.5-0.1 puede dar un resultado como

El tratamiento de la coma flotante ha sido uno de los mas problemáticos a la hora de realizar cálculos de precisión, dando como resultado números absurdos e infinidad de errores, por ejemplo era normal que el compilandore en casos tan triviales como 10-9 no diese 1, que era lo esperado sino un numero muy cercano a 1, por ejemplo 0,9999999, esto daba como resultado errores no esperados.

En España esto pasaba mas o menos desapercibido, y exploto en el momento del euro, aquí todos nos encontrábamos asombrados como, los malditos decimales bailaban y los contravalores finales no se ajustaban con lo esperado, por diferencias tontas, pero diferencias matemáticamente inaceptables.

así que lo suyo, era aumentar el espacio de almacenamiento en lugar de tener un numero codificado a 32bits, se paso a 64 y 128 bits

PDF Creator    Enviar artículo en formato PDF   

Calidad de software

Viernes, 20 de octubre de 2006

Durante los últimas semanas me estoy concienciando sobre el tema de la mal llamada calidad del software, en mi opinión la calidad siempre será la misma, porque esta mal llamada calidad de software no pretende mejorar el “ingenio” o eliminar la “torpeza”. Pero si que es cierto que bajo “calidad de software” al menos se alojan una serie de técnicas que no pueden ser cuestionadas, y evitan en gran medida el descontrol y la anarquía que suele aparecer en los proyectos medios.

Una vez tomados lo requisitos creo que las herramientas fundamentales para el control del desarrollo de un equipo, son:

  • Un sistema de control de versiones
  • Bugtracker
  • Dailybuild

Control de versiones

Quizás unos de los puntos mas importantes y que, sinceramente, la mayoría de las empresas olvidan, es el sistema de revisiones, por lo que he visto la mayoría se conforman con una carpeta compartida, donde se dejan todos los fuentes (con un copy de toda la vida), luego se añade un sistema de backups, mas o menos fiable, que se realizará todos los dias rezando porque no se necesite utilizar. Como cada programador se encarga de un módulo pues no se producen colisiones por lo que todos contentos. Los errores se comunicaban en post’it, y una vez al mes o cuando toque se hace la compilación conjunta y se crea el instalador, vamos el setup.exe de toda la vida. Este sistema funciona, ¿porque no?

El principal problema esta cuando se comparte el código de verdad, es decir cuando existe varios programadores que manejan una area común, como por ejemplo librerías. En este caso el ultimo en pasar los datos machacaría a los demás. Otro caso seria la recuperación de versiones anteriores, y por supuesto el control de ramas de aplicación, es decir podemos estar trabajando en la version 4.0 beta mientras tenemos la 3.5 como estable, la 4.0 puede ser una rama de la version 3.0 cuando la 4.0 esta en version estable se puede fisionar con la 3.5

Una vez convencidos de la necesidad de un sistema de versiones ahora queda, escojer uno, y como en todo este negocio, cada fabricante tiene el suyo, Sharepoint, cvs, svn, etc., el sistema de revisiones mas extendido era el CVS, ahora es sustituido por subversion o SVN, subversion tiene una mejora importante sobre CVS, que permite el ser montado sobre un servidor apache, de tal forma que el codigo puede ser compartido a traves de un servidor web, convencional. Las actualizaciones de los fuentes se realizan de una forma realmente rápida, y gracias a la herramienta TortoiseSVN, ademas es realmente facil. En principio yo tengo instalado este sistema bajo un servidor apache2, montado en un linux, y bajo una conexion adsl con ip fija, lo que me permite el trabajar en la oficina y fuera de ella.

El segundo punto fue instalar un bugtracker, que no es mas que un punto de encuentro de betatester y programadores, yo instale flyspray, una aplicación de desarrollada para un entorno LAMP, y realmente da buenos resultados.

En tercer lugar desarrolle las dailybuild, las compilaciones diarias, las cuales mediante un script, bastante cañero, permite el compilar, generar el setup up, subir al espacio web, y modificar la página, permitiendo ver los cambios en la nueva versión.

Con todo esto lo que hemos conseguido es un mejor control del proyecto, permitiendo no molestarnos, y dirigir el desarrollo a puntos especificos, pero el proyecto sigue siendo el mismo con la misma calidad, por eso me parece un poco pretencioso el definir los nuevos sistemas como “calidad” del software.

PDF Download    Enviar artículo en formato PDF