Aviso a navegantes.
Por estas fechas termino de impartir una serie de clases sobre programación C básica en sistemas Unix/Linux (Fedora y SunOS). Por este motivo voy a ir publicando aquí en los próximos días el código de los ejemplos y problemas extra que he ido proponiendo a mis alumnos.
También pondré de vez en cuando algún otro post como los que hay más abajo para que esto no se convierta en un monográfico C bajo Unix.
19.1.05
16.1.05
Convertir double a caddena
Saludos.
El otro día me preguntaron como pasar un tipo double a cadena con un número determinado de decimales, por ejemplo 2, en Java. Una posible solución se muestra a continuación:
El otro día me preguntaron como pasar un tipo double a cadena con un número determinado de decimales, por ejemplo 2, en Java. Una posible solución se muestra a continuación:
import java.text.DecimalFormat ;
public class Decimal {
public static void main(String args[]) {
double d1 = 123456789.123456789;
double d2 = 1.7976931348623157d;
double d3 = 4415961481999.03D;
DecimalFormat df = new DecimalFormat ("##############.##");
System.out.println ("d1:"+df.format(d1));
System.out.println ("d2:"+df.format(d2));
System.out.println ("d3:"+df.format(d3));
/**
Salida:
>java Decimal
d1:123456789,12
d2:1,8
d3:4415961481999,03
}
}
14.1.05
Pruebas como indicadores del avance de un proyecto.
¿Cuándo finaliza la construcción de un programa?. ¿Cuánto hemos avanzado esta semana?. ¿Vamos más rápidos o más lentos que el mes pasado?.
Todas estas preguntas se refieren a la velocidad con la que se crea o construye un programa y, en muchas ocasiones no son fáciles de responder. Una primera idea podría ser pensar que el avance de un programa tiene relación con las líneas de código escritas o número de clases implementadas, pero nada más lejos de la realidad. Es posible, por ejemplo, escribir 100.000 líneas de código o 50 clases en una semana y que el proyecto no avance ni un ápice, porque, por ejemplo, el código no funcione correctamente y necesite una depuración a fondo, o no pueda incorporarse al resto del programa o tenga que ser reescrito o, simplemente, se haya escrito código para una característica o función que no va a tener el sistema, por lo que no habrá servido de nada.
Una aproximación más fiable, pero aún no perfecta desde mi punto de vista, es relacionar el avance del proyecto con el cumplimiento de los requisitos. Un requisito es una característica que el sistema debe tener o algo que debe permitir hacer. A medida que vayamos escribiendo código, el sistema permitirá hacer cada vez más cosas, hasta que el sistema sea capaz de hacer todo lo que le piden los requisitos, momento en el que estará terminado. Sin embargo a veces es difícil cuantificar, a partir del código, el cumplimiento de requisitos. Por ejemplo, en un sistema típico de gestión comercial, si empleamos dos semanas en construir las bases de datos y las clases de acceso a las bases de datos (algo que será necesario para todos los requisitos), ¿qué grado de cumplimiento de los requisitos hemos conseguido un 1%, un 10%?. ¿Algún requisito habrá avanzado más que otro?. ¿Cuánto nos queda para satisfacer todos los requisitos?.
La mejor aproximación desde mi punto de vista, y que aúna características de las dos anteriores, es medir el avance del proyecto en función de la superación de pruebas. El proyecto estará terminado cuando sea capaz de superar todas las pruebas que lo verifiquen. Una semana se avanzará más que otra si ha sido capaz de superar todas las pruebas de la semana anterior y un número mayor de nuevas pruebas. Esta aproximación nos permite además, medir el desarrollo del código, mediante pruebas unitarias, y medir el cumplimiento de requisitos, mediante pruebas del sistema o pruebas de aceptación. En el momento en que ambas medidas alcancen el máximo, el sistema hará todo o que debe hacer sin errores en su código.
Un motivo más que justifica escribir pruebas para nuestros proyectos: no solo nos garantizan el cumplimiento de requisitos y la ausencia de errores, sino que nos permiten conocer el estado de nuestro proyecto, a que ritmo avanza y cuanto queda para su conclusión.
Todas estas preguntas se refieren a la velocidad con la que se crea o construye un programa y, en muchas ocasiones no son fáciles de responder. Una primera idea podría ser pensar que el avance de un programa tiene relación con las líneas de código escritas o número de clases implementadas, pero nada más lejos de la realidad. Es posible, por ejemplo, escribir 100.000 líneas de código o 50 clases en una semana y que el proyecto no avance ni un ápice, porque, por ejemplo, el código no funcione correctamente y necesite una depuración a fondo, o no pueda incorporarse al resto del programa o tenga que ser reescrito o, simplemente, se haya escrito código para una característica o función que no va a tener el sistema, por lo que no habrá servido de nada.
Una aproximación más fiable, pero aún no perfecta desde mi punto de vista, es relacionar el avance del proyecto con el cumplimiento de los requisitos. Un requisito es una característica que el sistema debe tener o algo que debe permitir hacer. A medida que vayamos escribiendo código, el sistema permitirá hacer cada vez más cosas, hasta que el sistema sea capaz de hacer todo lo que le piden los requisitos, momento en el que estará terminado. Sin embargo a veces es difícil cuantificar, a partir del código, el cumplimiento de requisitos. Por ejemplo, en un sistema típico de gestión comercial, si empleamos dos semanas en construir las bases de datos y las clases de acceso a las bases de datos (algo que será necesario para todos los requisitos), ¿qué grado de cumplimiento de los requisitos hemos conseguido un 1%, un 10%?. ¿Algún requisito habrá avanzado más que otro?. ¿Cuánto nos queda para satisfacer todos los requisitos?.
La mejor aproximación desde mi punto de vista, y que aúna características de las dos anteriores, es medir el avance del proyecto en función de la superación de pruebas. El proyecto estará terminado cuando sea capaz de superar todas las pruebas que lo verifiquen. Una semana se avanzará más que otra si ha sido capaz de superar todas las pruebas de la semana anterior y un número mayor de nuevas pruebas. Esta aproximación nos permite además, medir el desarrollo del código, mediante pruebas unitarias, y medir el cumplimiento de requisitos, mediante pruebas del sistema o pruebas de aceptación. En el momento en que ambas medidas alcancen el máximo, el sistema hará todo o que debe hacer sin errores en su código.
Un motivo más que justifica escribir pruebas para nuestros proyectos: no solo nos garantizan el cumplimiento de requisitos y la ausencia de errores, sino que nos permiten conocer el estado de nuestro proyecto, a que ritmo avanza y cuanto queda para su conclusión.
6.1.05
Límite de procesos en Unix/Linux
Saludos.
Preparando una clase de programación en C Unix/Linux he intentado hacer un ejemplo donde un gran número de procesos accedieran simultáneamente a un trozo de memoria compartida y los resultados no fueran los esperados. Con esto pretendía ilustrar la necesidad de garantizar la exclusión mútua.
No lo he conseguido. Mi Knoppix solo me ha permitido lanzar 487 procesos simultáneamente, mientra que SunOS me dejaba algunos más, hasta 496, 497 más o menos. Por desgracia con este número de procesos todo funcionaba a la perfección y, aunque no garantizara la exclusión mútua, ningún proceso se pisaba a otro.
Tnedré que escribir un programa donde fuerce la situación con unos sleep estratégicamente colocados.
Es una alegría que los Linux/Unix funcionen bien incluso cuando uno quiere que fallen.
Preparando una clase de programación en C Unix/Linux he intentado hacer un ejemplo donde un gran número de procesos accedieran simultáneamente a un trozo de memoria compartida y los resultados no fueran los esperados. Con esto pretendía ilustrar la necesidad de garantizar la exclusión mútua.
No lo he conseguido. Mi Knoppix solo me ha permitido lanzar 487 procesos simultáneamente, mientra que SunOS me dejaba algunos más, hasta 496, 497 más o menos. Por desgracia con este número de procesos todo funcionaba a la perfección y, aunque no garantizara la exclusión mútua, ningún proceso se pisaba a otro.
Tnedré que escribir un programa donde fuerce la situación con unos sleep estratégicamente colocados.
Es una alegría que los Linux/Unix funcionen bien incluso cuando uno quiere que fallen.
Subscribe to:
Posts (Atom)