09.05.2013 Views

Algoritmos y Programación en Pascal

Algoritmos y Programación en Pascal

Algoritmos y Programación en Pascal

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

150 Capítulo 7. <strong>Programación</strong> estructurada<br />

var<br />

c: integer; {el valor c<strong>en</strong>tral}<br />

...<br />

c:= (a + b) div 2<br />

Según c 2 sea:<br />

= N, hacer izda:= c; dcha:= c<br />

< N, hacer izda:= c + 1<br />

> N, hacer dcha:= c<br />

Veamos ahora si esta reducción es válida, es decir, si, sea cual sea sea el valor<br />

de c 2 <strong>en</strong> comparación con N, las asignaciones consecu<strong>en</strong>tes manti<strong>en</strong><strong>en</strong> m <strong>en</strong>tre<br />

izda y dcha y además la reducción es efectiva.<br />

El primer caso cumple trivialm<strong>en</strong>te esas exig<strong>en</strong>cias, al ser c 2 = N, y además<br />

produce la última reducción del intervalo.<br />

En los otros dos casos, debe t<strong>en</strong>erse <strong>en</strong> cu<strong>en</strong>ta que izda ≤ m ≤ dcha (invariante)<br />

y que el valor de c cumple que izda ≤ c < dcha, por ser a = b. En<br />

el segundo caso además, al ser c 2 < N, es seguro que m ≥ c + 1. Por consigui<strong>en</strong>te,<br />

tras la asignación izda:= c + 1, se puede asegurar que izda ≤ m y<br />

que izda ≤ dcha:<br />

{izda ≤ m ≤ dcha y izda ≤ c < dcha y c 2 < N}<br />

izda:= c + 1<br />

{izda ≤ m ≤ dcha}<br />

El tercer caso se deja como ejercicio.<br />

Trivialm<strong>en</strong>te se observa que, al ser izda ≤ c < dcha, cualquiera de los intervalos<br />

producidos por las tres ramas (c, c), (c+1, dcha) y (izda, c) es estrictam<strong>en</strong>te<br />

más pequeño que (izda, dcha), lo que asegura la terminación del bucle while.<br />

7.4.2 Recapitulación<br />

A t<strong>en</strong>or de lo expuesto <strong>en</strong> este capítulo podría parecer que el uso refinami<strong>en</strong>to<br />

progresivo y el uso de aserciones para comprobar la corrección de un programa es<br />

algo excesivo porque, <strong>en</strong> g<strong>en</strong>eral, se suel<strong>en</strong> escribir más líneas de seudocódigo y<br />

aserciones que de codificación propiam<strong>en</strong>te dicha. La v<strong>en</strong>taja es que se propicia<br />

el diseño correcto de algoritmos complejos.<br />

Por otro lado, es cierto que no todo programa se puede verificar, con lo cual<br />

¿de qué nos sirve todo esto? Nuestra propuesta consiste <strong>en</strong> adoptar un punto<br />

intermedio <strong>en</strong>tre la formalización absoluta que requiere la verificación rigurosa,<br />

y la aus<strong>en</strong>cia total de análisis sobre la corrección, esto es:<br />

1. Durante el proceso de apr<strong>en</strong>dizaje, examinar con detalle cada constructor<br />

que se apr<strong>en</strong>da, para habituarse a desarrollar algoritmos con garantías<br />

sufici<strong>en</strong>tes de que son correctos.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!