MANUAL DE PROGRAMACION TOMO 1

Ver el tema anterior Ver el tema siguiente Ir abajo

MANUAL DE PROGRAMACION TOMO 1

Mensaje  HERNAN DARIO RODRIGUEZ el Jue 26 Ago - 22:49:45

AUNQUE TIENE TERMINOS DE ESPAÑA, CONSIDERO QUE TIENE BUENAS COSAS Y SU REDACCION ES ENTENDIBLE.................................

INTRODUCCIÓN A LA PROGRAMACIÓN


Todos los lenguajes constan de unos determinados tipos de variables. Una variable es como una caja, donde ahora puedo meter un zapato y mañana un tomate. Ahora, yo puedo haber etiquetado mis cajas y decir "aquí sólo fruta": será una variable de tipo FRUTA. O, "aquí sólo legumbres": será una variable de tipo LEGUMBRE. Esto es interesante, porque en el momento en que yo vea FRUTA, ya sé que dentro no hay cerveza (y tendré que buscar en otro sitio...). Pero no sólo eso: yo sé que tengo muchas cajas para frutas, pero puedo querer bautizarlas ("tú serás la caja de frutas Juana"), y así llamarlas por su nombre. Podré cambiar (o no) su contenido (hoy Juana tiene un melón pero mañana le pondré ciruelas), pero NO lo que puede contener: FRUTA.
Esto también lo tiene en común los lenguajes de programación. Sólo que sus variables son de otro TIPO. Pueden ser enteros (sí, como los números que nos enseñaron en la infancia), números con decimales, cadenas de caracteres (no es más que un caracter detrás de otro) y otros que ahora no comentamos (quedan para más adelante).
Lo normal es declarar las variables al principio de un programa. Declarar no es más que decir "mira, yo quiero tres variables enteras, y quiero que una se llame Pepi, otra Juani y otra Yoli". A partir de este momento, podrás meter un -4 en Pepi, un 2 en Yoli, y hacer Pepi+Yoli. El resultado será -2.

¿Qué más cosas me permite hacer un lenguaje de programación? Pues me permite hacer operaciones conocidas por todos como sumar, restar, multiplicar y dividir.
Los lenguajes de programación, cuentan todos en su haber con un juego de "instrucciones". Una instrucción no es más que una orden que nosotros le damos a la máquina.
Y es que, al fin y al cabo, un PROGRAMA no es más que una secuencia de instrucciones (escritas en algún lenguaje de programación) pensado para RESOLVER algún tipo de PROBLEMA. Si no sabemos resolver este problema, no podremos escribir el programa.
A ti se te puede ocurrir una manera de resolverlo. A tu vecino, otra. Este METODO con el que resolves el problema, es lo que se llama ALGORITMO.
Un algoritmo no es más que una secuencia de pasos que, seguidos uno a uno, me permiten resolver un problema.
Por ejemplo, cuando quiero ver una película de vídeo, podría hacer:
1. Elijo una película de las de mi colección.
2. Compruebo SI TV y vídeo están conectados a la red (y procedo).
3. SI la TV está apagada, la enciendo, SI NO, pues no. Y lo mismo con el vídeo.
4. Abro el estuche de la película.
5. Saco la película de su estuche.
6. Introduzco la película en el vídeo. Dejo el estuche sobre el vídeo.
7. SI la TV no está en el canal adecuado, la cambio, SI NO, pues no.
8. Cojo los mandos a distancia (el del TV y el del vídeo).
9. Me pongo cómodo.
10. Pulso PLAY en el mando del vídeo.

¿A qué no se os había ocurrido?
Fijaos bien en unos detalles que son fundamentales y que aparecen en este algoritmo:
1. La descripción de cada paso no me lleva a ambigüedades: los pasos son absolutamente explícitos y no inducen a error.
2. El número de pasos es finito.
Y es que no puedes tener eternamente pensando a la máquina si pretendes que te dé algún resultado en algún momento.
Podría poner una definición rigurosa de lo que es un algoritmo, pero me parece que con esto se coge la idea.
Notar también que he escrito en mayúsculas las palabras SI y SI NO. Como podeis imaginar, formar parte de la manera en que se escriben algoritmos.
Por ahora, os invito a que describais algorítmicamente situaciones cotidianas de vuestra vida. En la próxima entrega haré un resumencito escribiendo las cosas de forma algo más rigurosa (al principio lo que importa es que se entiendan las ideas), completaré lo dicho sobre las variables, y seguiremos por esos pecaminosos senderos del mundo de la programación: las instrucciones de control de un programa.

Las variables, usos y costumbres
La vez anterior nos quedamos hablando de variables, aquellas cajitas donde podemos ir almacenando cosas como lechugas, tomates y también...
ENTEROS:
Como su nombre indica, aquí podremos meter números enteros, tanto positivos como negativos. Cuando decimos que podemos tener tanto enteros positivos como negativos, lo que se suele decir es "enteros con signo". Si sólo vamos a tener enteros positivos (incluyendo el cero), decimos entonces "enteros sin signo". Esta nomenclatura de "con signo" y "sin signo" es aplicable a otros tipos, como el siguiente.
REALES:
Trex cuartos de lo mismo, aquí podemos poner números con decimales, tanto positivos como negativos. Hay reales con signo y reales sin signo, pero, si no decimos lo contrario, se sobreentiende que son con signo.
Obviamente, dado que la memoria de la máquina es finita (vamos, que por muchos megas, incluso Gigas de RAM, algún día ésta se nos acabará), el tamaño de los datos que almacenemos también será finito. Esto quiere decir que, por ejemplo, el número Pi jamás cabrá en la memoria de un ordenador. Por tanto, para cada tipo de dato, según el lenguaje, se especifica cuántas cifras tiene, aunque suele ser unánime.
CARACTERES:
Si tenemos una variable de tipo caracter, lo que podemos almacenar será un caracter como 'p', 's', '3', '#' y otros.
Estos son los tres tipos de datos básicos, y son los que yo usaré. Como ya comenté, las variables se suelen declarar al principio del programa, y esta será la norma que yo voy a usar; toda variable utilizada, debe haber sido previamente declarada. Para ello, escribiré algo como esto:
Declaracion de variables:

ENTERO: i,j,k
REAL: x,y,z
CARACTER: a,b,c

Fin de la declaracion de variables
Esto querrá decir que las variables i, j, k serán enteras (con signo), que las variables x, y, z serán reales (con signo) y que las variables a, b, c serán caracteres. Al escribir la declaración de variables de esta forma, si alguna se nos ha olvidado, es muy fácil incluirla.
Una variable, en el momento que la declaramos, está vacía, hueca, sin vida, sentido ni VALOR. Y hasta que dicha variable no tenga valor, lo mejor será no hacer cosas con ella. Entonces, aquí viene la pregunta: ¿y cómo meto en mi variable un 7? ¿Puedo meter un 23?
Para poder meter cosas en las variables, lo que hacemos es asignarles un valor, es decir, "Pepe es una variable de tipo entero. Si a Pepe le asigno 14, a partir de ahora, poner Pepe es tanto como poner 14".
Para ello, nosotros vamos a usar un símbolo, una flechita. Cuando queramos hacer asignaciones, haremos esto:
Pepe <- 14 (asignamos un entero)
Carolina <- -9.65 (asignamos un real)
Juan <- 'a' (asignamos un caracter)
Y podemos hacer cuantas asignaciones queramos a nuestra variable. Por ejemplo, si hacemos:
Pepe <- 14
Pepe <- 4
Pepe <- -3
Pepe <- 42
al final, en Pepe tenemos almacenado el valor 42.
Lo que no debemos hacer es:
Pepe <- 14
Pepe <- 2.5
pues estamos metiendo un valor REAL en una variable que sólo quiere ENTEROS. ¿Qué pasará aquí? Pues depende del compilador. Quizá nos trunque los decimales, quizá los redondee, quizá, simplemente, nos dé un error y no lo permita. En cualquier caso, si queríamos un 2.5 con toda nuestra alma, una variable entera no es lo más recomendable para guardarlo.
"Muy bien, ya sé cómo meter cosas en las variables, ahora... ¿qué puedo hacer con mis variables?"
Como los caracteres son un tanto especiales, serán tratados aparte, para que no haya confusión. Así que, por ahora, nos vamos a entender con las variables numéricas.
Como obviamente parece, podemos sumar, restar, multiplicar y dividir variables. Si dividimos por una variable que en ese momento valga cero, tendremos un error. Pero, por lo demás, podemos hacer todas estas cosas.
Por el mismo motivo que he comentado arriba, es mejor no mezclar enteros con reales al hacer operaciones, a no ser que de verdad uno sepa que quiere mezclarlos y por qué quiere mezclarlos.
Para estas operaciones, usaremos la notación usual que nos enseñaron ya desde pequeñitos. Entonces, podremos hacer todas estas cosas:
Pepe <- 2
Mari <- 3
Juan <- Pepe*Mari
Tendremos que en Juan está almacenado el valor 2*3=6 Smile
Pepe <- 2
Mari <- 3
Juan <- Pepe+Mari
Ahora, en Juan está almacenado el valor 2+3=5 Smile
Pepe <- 2
Mari <- 3
Juan <- Pepe-Mari
Y ahora, en Juan está almacenado el valor 2-3=-1 Smile
Como estos, os podeis poner cuantos ejemplos querais.
Además, los compiladores suelen traer librerías matemáticas con muchas funciones más avanzadas (aunque *todas* esas funciones se consiguen a partir de las cuatro operaciones básicas), funciones con las que podemos hacer más operaciones con nuestras variables.
Por ejemplo, podemos escribir:
Mari <- Pi
Pepe <- sin(Mari)
Y tendremos en Pepe almacenado el valor sin(Pi)=0
Más adelante, os pondré como ejercicio implementar alguna función matemática como el seno, la exponencial (u otras), el algoritmo será muy sencillo, y vereis como todos los cálculos no son más que combinaciones de las cuatro operaciones básicas que nos enseñaron en la escuela.
De momento, eso es todo en cuanto a variables numéricas.
Las variables de tipo carácter son un poco más especiales, es mejor esperar a tener un poco más de rodaje en otras cuestiones básicas.

Estructuras de control; secuenciales y selectivas
Bueno, bueno: ya hemos hablado un poco de variables; qué son, y cosas que podemos hacer con ellas. También hablamos un poco por encima de lo que es un algoritmo, pero aún no sabemos cosas sobre ellos. Una posible "definición rigurosa" sería la siguiente (no hay que tomarla como un dogma de fe):
Un algoritmo es una sucesion finita de pasos no ambiguos que se pueden llevar a cabo en un tiempo finito.
Sucesión finita es lo contrario de infinita: esto quiere decir que se acaba en algún momento Wink
Pasos no ambiguos son pasos tan claros que hasta una máquina los puede entender, de ahí la necesidad de la no ambigüedad Wink
Lo del tiempo finito es una cuestión práctica: no creo que tengamos tanta paciencia (ni que lleguemos vivos, sobre todo) como para ver la salida de un programa que calcule Pi Smile
No vamos a entrar en filosofías de qué puede ser considerado como un algoritmo, qué no lo es, etc... , no porque no sea interesante en sí, sino porque a nosotros lo que nos preocupa en estos momentos es aprender a resolver problemas, y a eso es a lo que vamos.
No hay que confundirse: un algoritmo no es lo mismo que un programa, para hacer un programa necesitamos algo más: unas estructuras de datos.
Hay distintas formas de escribir un algoritmo, bien usando un lenguaje específico de descripción de algoritmos, bien mediante representaciones gráficas.
Yo he elegido la primera: el pseudocódigo. Que sea un lenguaje específico no significa que haya que aprender un idioma nuevo, lo único que quiere decir es que hay unas cuantas palabras que son clave, y que son las palabras que, de acuerdo a unas reglas muy sencillitas, nos ayudan a describir el algoritmo.
La estructura del pseudocódigo es bastante parecida a la de algunos lenguajes de programación (por ejemplo, el Pascal), por ello me ha parecido la más recomendable.
El pseudocódigo tiene algunas ventajas:
• Es fácil hacer cambios si nos equivocamos en la lógica del programa
• Es independiente del lenguaje de programación que vaya a usarse; un algoritmo que esté escrito en pseudocódigo es fácilmente traducible a muchos lenguajes de programación.
Y ya, sin más preámbulos, vamos a lo que nos interesa: nosotros queremos resolver problemas con el ordenador, ¿no es así? Pues veamos con qué herramientas nos podemos defender para escribir nuestros propios algoritmos.
Elementos básicos para la descripción de algoritmos
El principio y el fin
Para delimitar el comienzo y el final de un algoritmo, o de un trozo de algoritmo (por ejemplo, en los bucles, y otros, como vamos a ver), haremos lo siguiente:
inicio

... Aqui va el algoritmo en cuestion

fin
También, en vez de inicio y fin se puede usar "empezar" y "fin", o lo que querais, pero siempre quedando clara la intención. No hay que ser estrictamente riguroso con la aplicación del "inicio-fin", muchas veces, una buena indentación hace su papel.
Asignaciones
Sobre las asignaciones ya hablamos la vez pasada, al tratar el tema de las variables, vamos a recordarlo brevemente:
Cuando hayamos declarado una variable, llegará un momento en el que querremos que la variable tome algún valor. Por ejemplo, tenemos una variable de tipo entero que se llama I y queremos asignarle el valor 3, entonces, escribiremos:
I <- 3
Comentarios
Poner comentarios de lo que vamos haciendo es muy útil, sobre todo cuando llega la hora de revisar el algoritmo, si no, más de una vez nos encontraremos diciendo "uumm... ¿qué demonios hacía esto?"
No cuesta nada documentar el código y nos ahorrará dolores de cabeza Smile La convención que seguiremos será poner los comentarios entre llaves. Así, {esto será un comentario}
Estructuras de control
Las estructuras de control tienen una finalidad bastante definida: su objetivo es ir señalando el orden en que tienen que sucederse los pasos de un algoritmo.
Veamos un ejemplo: supongamos que acabamos de mostrar un mensaje en la pantalla que pregunte al usuario "¿desea seguir adelante?".
Obviamente, de la respuesta del usuario va a depender la siguiente acción del programa. Por ejemplo, si este mensaje se nos presenta tras haber pulsado un botón de cerrar la aplicación, si nosotros elegimos "Sí", la aplicación se cerrará, y si elegimos "No", la aplicación seguirá adelante. El programador tiene que haber escrito código para las dos posibilidades, aunque cuando el programa esté funcionando, sólo se elegirá una.
Las estructuras de control son de tres tipos:
1. Secuenciales
2. Selectivas
3. Repetitivas
Estructuras secuenciales
Una estructura de control secuencial, en realidad, no es más que escribir un paso del algoritmo detrás de otro, el que primero se haya escrito será el que primero se ejecute (al implementarlo, por ejemplo).
Veamos un ejemplo: queremos leer el radio de un círculo, calcular su área y mostrar por pantalla al usuario el resultado.
Declaracion de variables
REAL: radio, area
fin declaracion de variables

inicio
mostrar por pantalla 'dame el radio del circulo'
leer del teclado la variable radio
area <- 3.14159*radio
mostrar por pantalla 'el area del circulo es:'
mostrar por pantalla el contenido de la variable area
fin
Notar una cosa: cuando queremos hacer cosas relativas a entrada o salida por algún dispositivo, como el teclado, la pantalla o la impresora, yo pongo cosas como "mostrar por pantalla", o "leer del teclado". Dado que cada lenguaje de programación tiene sus funciones de entrada/salida, no uso la forma particular de ninguno, simplemente, lo que le diríamos al ordenador en caso de que fuera una persona ("oye, por favor, sácame esto por impresora").
Por otro lado, cuando queramos decir que nos muestre el contenido de una variable, yo he puesto "mostrar por pantalla el contenido de la variable area", pero podía haber puesto igualmente "mostrar por pantalla area", o cosas similares. Vosotros elegís la forma que os resulte más clara o más cómoda, lo importante es que las intenciones sean claras, o, lo que es lo mismo, "no ambiguas" Wink
Además, si os fijais, para que quede claro que una cosa es mostrar por pantalla una cadena, y otra cosa es mostrar por pantalla el valor de una variable, el texto que aparece entre ' ' es una cadena, mientras que el que no aparece entre ' ' no es una cadena, sino que se refiere a una variable.
Ahora vamos a pasar a las estructuras selectivas y a las repetitivas. Para ello, necesitamos primero hablar un poco de... CONDICIONES.
La palabra condición nos sugiere frases como "lo haré a condición de que me dejes tu boli". Analicemos esta frase con un poco de detenimiento.
Decimos "lo haré", pero, ¿"lo haré" siempre, pase lo que pase? o, por el contrario, ¿"lo haré" si antes hay algo que debe cumplirse? En la frase está claro que no se ha dicho "lo haré" sin más, si no que hay como una pequeña cláusula "SI me dejas tu boli".
Ya nos ha vuelto a aparecer el SI; esto parece querer decir que debe ser algo importante.
Lo que significa "SI me dejas tu boli" es lo siguiente, en caso de que la acción "dejarme tu boli" sea cierta (o verdad, usaré ambas palabras), yo "lo haré". Pero si la acción "dejarme tu boli" es falsa (o mentira), yo NO "lo haré".
En esto reside el "quid" de las estructuras que vamos a ver a continuación: se EVALUA una condición, y se actúa en consecuencia, según que la condición sea VERDADERA o FALSA.
Estructuras selectivas
Estas estructuras se utilizan para TOMAR DECISIONES (por eso también se llaman estructuras de decisión o alternativas). Lo que se hace es EVALUAR una condición, y, a continuación, en función del resultado, se lleva a cabo una opción u otra.
Alternativas simples
Son los conocidos "si... entonces". Se usan de la siguiente manera (una vez más, la escritura es más o menos personal, siempre que las intenciones queden claras para todos): yo quiero evaluar una condición, y si se cumple (es decir, si es cierta), entonces realizaré una serie de pasos. Esto lo podemos escribir así:
SI se cumple la condicion, ENTONCES:
Hago el paso 1
....
Hago el paso N
fin del SI
Muy estrictamente, sería:
SI se cumple la condicion, ENTONCES:
inicio
Hago el paso 1
....
Hago el paso N
fin
fin del SI
pero con una buena sangría nos podemos evitar escribir de más Wink
Es importante cerrar el SI, ya que, si no se cumple la condición, el programa seguirá a continuación de donde termina el SI.
Por ejemplo, queremos calcular la raíz cuadrada de un número; sin embargo todos sabemos (¡supongo! Wink) que la raíz cuadrada de un número negativo NO es un número real. Esto quiere decir que, tras leer el número por teclado, tendremos que ver si es positivo, ya que sólo en este caso podremos calcular su raíz cuadrada.
Veamos como queda:
Declaracion de variables
REAL: numero, raiz
fin declaracion de variables

inicio
mostrar por pantalla 'introduce un numero'
leer del teclado la variable numero
SI numero >= 0 ENTONCES:
raiz <- raiz_cuadrada(numero)
mostrar por pantalla 'la raiz cuadrada es:'
mostrar por pantalla raiz
fin del SI
fin
Como extraer una raíz cuadrada es una operación que, en principio, no es elemental, yo he puesto raiz_cuadrada(numero), eso significa que, en alguna parte, tengo definida una función que me calcula la raíz cuadrada de un número. Ya hablaremos de funciones y subrutinas más adelante, pero hago esta aclaración para que conste que raiz_cuadrada no forma parte de ningún tipo de especificación de pseudocódigo ;-)
Sin embargo, hubiera sido bonito haber podido avisar al usuario de que no podíamos calcular la raíz cuadrada en caso de que el número fuera negativo, pero no os preocupeis, para ello tenemos las...
Alternativas dobles
O el famoso trío "si ... entonces ... sino" ;-D
Se usan de esta forma: queremos evaluar una condición, si es verdad, realizaré una serie de pasos, y SI NO es verdad (es decir, si es falsa, si es una puerca mentira cochina... Wink ), entonces realizaré otra serie de pasos. Esto lo podemos escribir así:
SI se cumple la condicion, ENTONCES:
Hago el paso A1
....
Hago el paso AN
y SI NO se cumple la condicion, ENTONCES:
Hago el paso B1
....
Hago el paso BM
fin del SI
Con esto, nuestro algoritmo para la raíz cuadrada quedaría:
Declaracion de variables
REAL: numero, raiz
fin declaracion de variables

inicio
mostrar por pantalla 'introduce un numero'
leer del teclado la variable numero
SI numero >= 0 ENTONCES:
raiz <- raiz_cuadrada(numero)
mostrar por pantalla 'la raiz cuadrada es:'
mostrar por pantalla raiz
SI NO es numero >=0 ENTONCES: {es decir, si numero es negativo}
mostrar por pantalla 'lo siento, no puedo calcular
la raiz cuadrada de un numero negativo'
fin del SI
fin
Alternativas múltiples
Es muy probable que tengamos la necesidad de incluir en nuestros programas alternativas con muchas opciones posibles. Esto lo podríamos hacer a base de anidar "si ... entonces ... si no", pero si es un número elevado de alternativas, se hace demasiado farragoso como para resultar inteligibles. Por ejemplo, si queremos hacer un menú que dé a elegir cuatro opciones, un posible algoritmo sería:
{Algoritmo MENU a base de 'si ... entonces ... sino'}
Declaracion de variables
ENTEROS: opcion
fin declaracion de variables

inicio
mostrar por pantalla 'menu de opciones:'
mostrar por pantalla '1. Diccionario de sinonimos'
mostrar por pantalla '2. Diccionario de antonimos'
mostrar por pantalla '3. Buscar palabra'
mostrar por pantalla '4. Salir'
leer del teclado la variable opcion

SI opcion = 1 ENTONCES
{lo que toque a esta opcion}
SI NO, ENTONCES
SI opcion = 2 ENTONCES
{lo que toque a esta opcion}
SI NO, ENTONCES
SI opcion = 3 ENTONCES
{lo que toque a esta opcion}
SI NO, ENTONCES
SI opcion = 4 ENTONCES
{lo que toque a esta opcion}
SI NO, ENTONCES
mostrar por pantalla 'opcion incorrecta'
fin del SI
fin del SI
fin del SI
fin del SI
fin
Farragoso, ¿verdad?
Para evitar esto (¿os imaginais que en vez de cuatro fueran 20 las alternativas?), está la estructura "según sea". La idea es esta; por ejemplo, como en el algoritmo que hemos puesto del menú, pedimos al usuario que entre una opción, y hay cuatro posibilidades, cuatro posibles valores para los que haremos algo.
Entonces, SEGUN lo que valga la variable opción, elegiremos una alternativa de entre todas las posibles.
La forma de escribir esto en pseudocódigo es:
SEGUN SEA la variable o la expresion HACER
VALOR1: {las acciones que toque}
...
VALORN: {las acciones que toque}
por defecto: {las acciones que toque}
fin SEGUN
¿Qué pinta ahí ese 'por defecto'?
No es más que una alternativa por si acaso se elige alguna opción no contemplada entre las que se ofrece.
Como ejemplo, vamos a ver nuestro menú utilizando la alternativa múltiple SEGUN SEA:
{Algoritmo MENU a base de 'segun sea'}
Declaracion de variables
ENTEROS: opcion
fin declaracion de variables

inicio
mostrar por pantalla 'menu de opciones'
mostrar por pantalla '1. Diccionario de sinonimos'
mostrar por pantalla '2. Diccionario de antonimos'
mostrar por pantalla '3. Buscar palabra'
mostrar por pantalla '4. Salir'
leer del teclado la variable opcion

SEGUN SEA opcion HACER:
opcion = 1 : {lo que toque a esta opcion}
opcion = 2 : {lo que toque a esta opcion}
opcion = 3 : {lo que toque a esta opcion}
opcion = 4 : {lo que toque a esta opcion}
por defecto: {mostrar un posible mensaje de error}
fin SEGUN
fin
Así queda mucho más claro, no sólo para nosotros, si no para cualquier persona que tuviera que leerlo; además, es una forma más sencilla de manejar una alternativa múltiple Smile
Podemos abreviar un poquito el texto; es igualmente válido poner, dentro del SEGUN, lo siguiente:
SEGUN SEA opcion HACER:
1 : {lo que toque a esta opcion}
2 : {lo que toque a esta opcion}
3 : {lo que toque a esta opcion}
4 : {lo que toque a esta opcion}
por defecto: {mostrar un posible mensaje de error}
fin SEGUN
Me quedan las estructuras repetitivas, que las veremos en la próxima entrega, si no esto puede ser mucho trago de golpe O:)
En cualquier caso, ya teneis cosas para ir empezando a pensar en la escritura de algoritmos. Yo sugiero los siguientes...
Ejercicios
Sobre estructuras secuenciales
1. Escribid un algoritmo que calcule el área de un triángulo.
2. Escribid un algoritmo que calcule el área de un rectángulo.
3. Escribid un algoritmo que calcule el área de un trapecio.
4. Escribid un algoritmo que calcule el precio de un artículo tras aplicarle un 16% de IVA.
5. Escribid un algoritmo que intercambie el contenido de dos variables.
Sobre estructuras selectivas
1. Escribid un algoritmo que resuelva una ecuación de segundo grado, teniendo en cuenta todas las posibles alternativas.
2. Diseñad un esquema de menú de opciones, por ejemplo, un menú para seleccionar un libro a leer de entre siete disponibles.
3. Escribid un algoritmo que lea tres números e imprima por pantalla el mayor de ellos.
4. Escribid un algoritmo que lea tres números e imprima por pantalla el menor de ellos.
De momento, eso es todo, cuando tengamos las estructuras repetitivas ya podremos hacer muchas más cosas Smile
Estoy *especialmente* interesada en el ejercicio 5 de las estructuras secuenciales y en el ejercicio 4 de las selectivas, lo digo por si no podeis hacer toda la faena... Wink

Estructuras de control; repetitivas
Vamos a ver un poco de teoría primero, porque si no, no sé dónde meterla ni cómo contarla sin que parezca un insulto. Perdonadme que esto sea un pelín rollero las primeras 40 líneas (o así), y ya el resto lo explico con ejemplos. No la contaría si no fuera necesaria O:)
Estructuras repetitivas
Este tipo de estructuras marcan como orden de ejecución la reiteración de una serie de acciones basándose en un bucle.
Un BUCLE (loop, en inglés) es un trozo de algoritmo cuyas instrucciones son repetidas un cierto número de veces, mientras se cumple una cierta condición que ha de ser claramente especificada. La condición podrá ser verdadera o falsa, y se comprobará en cada paso o iteración del bucle.
Básicamente, existen tres tipos de estructuras repetitivas; los bucles "mientras..." (o "while"), los bucles "repetir... mientras que" (o "do... while") y los bucles "desde" (o "bucles for"). Vamos a verlas todas dentro de un ejemplo para clarificar los dos párrafos iniciales, que quedan tan bonitos como oscuros para quien nunca ha visto un bucle (ni es verde ni tiene antenas, lo siento %-D ).
Sólo un poco de teoría más antes de pasar a los ejemplos para cada una de las estructuras repetitivas; hay que hacer notar que todo bucle consta de tres partes básicas, a saber:
• Decisión: donde se evalúa la condición y, en caso de ser cierta, se ejecuta el...
• Cuerpo del bucle: son las instrucciones que queremos ejecutar repetidamente un cierto número de veces.
• Salida del bucle: es la condición que dice cuándo saldremos de hacer repeticiones ("mientras protestes, seguirás fregando platos", en cuanto dejas de protestar, se acabó fregar más platos).
Una forma de controlar un bucle es mediante una variable llamada CONTADOR, cuyo valor se incrementa o decrementa en una cantidad constante en cada repetición que se produzca.
También, en los bucles suele haber otro tipo de variables llamadas ACUMULADOR, cuya misión es almacenar una cantidad variable resultante de operaciones sucesivas y repetidas. Es como un contador, con la diferencia que el incremento/decremento es variable.
Sí, sí, sí... ya sé que no me habeis entendido ni jota... ya vamos a por ejemplos, y ahí vereis a qué me refiero.
Una situación real como aplicación
Vamos a suponer que estamos pensando en un programa que deba REPETIR algunas veces una acción. Por ejemplo, el ordenador se ha portado mal (el güindoze se ha vuelto a colgar, no sé, por decir algo };-D ), y, como castigo, le vamos a hacer imprimir por pantalla 300 MILLONES de veces la frase "Prometo ser bueno O:-)"
¿Cómo lo hacemos? ¿Escribimos 300.000.000 de veces la instrucción pertinente? ¡Vaya martirio! ¡Ni con "Copy'n'Paste"! ¡Se supone que el castigo es para la máquina, no para uno mismo!
Pues bien, las ESTRUCTURAS REPETITIVAS vienen a rescatarnos de la tediosa tarea de repetir cientos de líneas que en unas pocas quedan apañadas.
Estructura MIENTRAS(condición)
En este tipo de estructura, el cuerpo del bucle (ya sabeis, las acciones que deben ejecutarse repetidas veces) se repite MIENTRAS se cumple una determinada condición, que especificamos entre paréntesis.
Su estructura, genéricamente, es esta:
mientras(condición) hacer
acción 1
........
acción N
fin mientras
Aplicado a nuestra situación real, sería:
Declaración de variables
ENTEROS: Contador
fin Declaración variables

inicio

Contador <- 1
mientras(Contador<=300.000.000) hacer
mostrar por pantalla 'Prometo ser bueno O:-)'
Contador <- Contador+1
fin mientras

fin
Con toda la idea, a la variable que "lleva" (por decirlo de alguna manera) la cuenta de las veces que el bucle se ha ejecutado, la he llamado contador.
Si os fijais, ANTES de entrar en el bucle le asigno el valor 1. Recordad que no es recomendable usar variables no inicializadas, no sabemos qué tienen dentro. En cuanto vemos la palabra "mientras", ya sabemos que hemos entrado en el bucle. Estamos en la decisión. ¿Es Contador<=300.000.000? Yo creo que sí, al menos si es cierto que 1<=300.000.000
Vale, es cierto, así que deben ejecutarse todas las instrucciones del cuerpo del bucle. En nuestro caso, se mostrará por pantalla la frase 'Prometo ser bueno O:-)', y, ATENCION, sumo 1 a la variable Contador. Como Contador valía 1, si ahora le sumo 1, creo que todos estamos de acuerdo en que ahora Contador vale 2. Llegamos al fin del mientras. Eso significa que se han terminado las instrucciones del cuerpo del bucle: debemos volver a evaluar la condición que tenía el "mientras" entre paréntesis para ver qué hacemos ahora.
Tenemos que ver si Contador<=300.000.000. Ahora, Contador valía 2, y se cumple que 2<=300.000.000, con lo que vuelve a mostrarse por pantalla la expresión 'Prometo ser bueno O:-)' y de nuevo se suma 1 a Contador, con lo que ahora, Contador pasa a valer 3. De nuevo llegamos al fin del mientras.
[... un buen rato después...]
Ahora Contador vale 300.000.000. Tenemos que ver si Contador<=300.000.000. Como es cierto que 300.000.000<=300.000.000, se muestra por pantalla el mensaje 'Prometo ser bueno O:-)', y sumamos 1 a Contador. Ahora, Contador vale 300.000.001. Llegamos (una vez más) al fin del mientras, por lo que tenemos que volver a evaluar la condición entre paréntesis que acompaña al "mientras".
Hay que ver si Contador<=300.000.000. Pero no es cierto que 300.000.001<=300.000.000, es más bien al revés, o sea, la condición entre paréntesis ES FALSA, ES UNA MENTIRA. ¿Eso qué quiere decir? Pues quiere decir que se acabó, que ya no se ejecuta el cuerpo del bucle, sino que hemos llegado al final, a la salida del bucle, con lo cual, el bucle ha terminado.
¿Me podría decir alguien qué hubiera pasado si no incluimos la línea "Contador <- Contador+1" dentro del cuerpo del bucle?
Sólo adelanto que se llegaría a una situación que debe evitarse por completo; si tenemos suerte, habrá un error de desbordamiento, en el peor de los casos, el bucle... completad la frase Wink
Una nota importante:
Fijaos en una cosa, si, por ejemplo, al empezar nuestro algoritmo, en vez de hacer
Contador <- 1
hubiéramos hecho
Contador <- 1.000.000.000.000.000.000
aparte de que tenemos posibilidades de salirnos de rango (vamos a suponer que no fuera así), al entrar en el mientras, la condición es "Contador<=300.000.000", y Contador es, claramente, mayor estrictamente que 300.000.000
¿Qué pasaría aquí? Pues es sencillo: la condición es falsa, luego el cuerpo del bucle se ejecuta CERO veces. ¿Y qué utilidad tiene poner un bucle para que luego no se ejecute? En este caso concreto, ninguna, pero puede haber situaciones en las que sí nos sea útil. De hecho, sucede a menudo Smile
Estructura REPETIR... MIENTRAS QUE(condición)
Aquí, lo que se desea es que un bucle se ejecute AL MENOS UNA VEZ antes de comprobar la condición de repetición.
La estructura del REPETIR ... MIENTRAS, genéricamente, es esta:
repetir
acción 1
........
acción N
mientras que(condición)
Notar que no hace falta poner "fin del repetir", puesto que está claro que se acaba donde pone "mientras que(condición)".
Vamos a ver cómo resolver nuestra situación REAL con este tipo de estructura:
Declaración de variables
ENTEROS: Contador
fin Declaración variables

inicio

Contador <- 1
Repetir
mostrar por pantalla 'Prometo ser bueno O:-)'
Contador <- Contador+1
mientras que(Contador<=300.000.000)

fin
Le seguimos la pista igual que se la hemos seguido al anterior caso: empezamos con la asignación del valor 1 a la variable Contador. Llegamos a repetir, quien NO NOS EXIGE, para su entrada, verificar condición alguna. Mostramos por pantalla la frase 'Prometo ser bueno O:-)', y sumamos 1 a la variable Contador, con lo que ahora pasa a valer 2. Y AHORA es cuando llegamos a la condición: ¿es Contador<=300.000.000? Yo diría que sí, así que ale, de vuelta a repetir: mostramos por pantalla nuestra frase, sumamos 1 a contador...
[... varios minutos después...]
Y ya, por fin, Contador alcanza el valor 300.000.001, con lo que la comparación dice "¡MENTIRA!", y se acabó repetir esa tarea.
Nuevamente, os invito a que me digais qué hubiera pasado si no hiciéramos Contador <- Contador+1 ...
Otra nota importante:
Vamos a remarcar una diferencia IMPORTANTE entre esta estructura y la anterior "mientras". Si al empezar nuestro algoritmo, en vez de hacer
Contador <- 1
hubiésemos hecho
Contador <- 1.000.000.000.000.000.000
de nuevo tenemos posibilidades de salirnos de rango, pero va, vamos a poner que esto que no fuera así; la palabra REPETIR no nos está pidiendo nada, así que ejecutamos una vez el cuerpo del bucle. Se nos muestra la frase, se incrementa el contador, y llegamos al mientras. Como la condición es falsa, no volvemos a ejecutar el bucle.
¿Cuál es la diferencia?
Pues que con la estructura "mientras", el bucle se ejecutaba CERO veces, sin embargo, con la estructura "repetir...mientras que" el bucle se ejecuta UNA vez. Esta sutil diferencia es la que hace que unas veces se elija al primero y otras al segundo.
Estructura DESDE
Esta estructura hubiera sido la más adecuada para resolver nuestra situación real, como veremos a continuación.
La estructura "desde", tiene una pequeña peculiaridad, y es que ella solita incrementa (o decrementa) DE UNO EN UNO a la variable que utilicemos como contador.
Su estructura es:
desde Contador<-Inicio hasta Contador=Fin [, decrementar,] hacer
accion 1
........
accion N
fin desde
La palabra "decrementar" entre corchetes significa que es opcional, es decir, que se puede poner o no. Si NO se pone, por defecto se asume que al terminar las acciones del bucle, se hará Contador <- Contador+1
Si ponemos "decrementar", al terminar las acciones del bucle se hará Contador <- Contador-1. Cuidado con esto, pues si no especificamos "decrementar", es ILEGAL escribir
desde Contador<-500 hasta Contador=200 hacer
así como, si escribimos "decrementar", es igualmente ILEGAL poner
desde Contador<-1 hasta Contador=1257 , decrementar, hacer
No se admite otro tipo de incrementos/decrementos (de 2 en 2, de 0.5 en 0.5 o de -10 en -10), para ello ya tenemos las estructuras "mientras" y "repetir...mientras", en las que nosotros elegíamos el incremento/decremento.
En el lenguaje de programación Pascal esto también sucede así en los bucles FOR. En otros lenguajes, como FORTRAN, BASIC o C, el FOR es mucho más potente, siendo el caso del lenguaje C el que riza el rizo, pudiendo llegar a hacer verdaderas obras de arte con un "simple" bucle FOR.
Bueno, al grano O:)
Supongo que la estructura está suficientemente clara, sin embargo, para terminar de clarificarla, vamos a aplicarla a nuestra BIEN conocida situación REAL:
Declaración de variables
ENTEROS: Contador
fin Declaración variables

inicio

desde Contador<-1 hasta Contador=300.000.000 hacer
mostrar por pantalla 'Prometo ser bueno O:-)'
fin desde

fin
Umm... lo primero que se observa es que no hace falta asignar el valor 1 a Contador fuera del bucle, puesto que en la parte Contador<-Inicio (Contador<-1, en este caso) ya se asigna automáticamente ese valor.
Lo siguiente es, como ya he mencionado, que no hace falta que incrementemos el valor de Contador, puesto que es una acción que se realiza sola en un bucle de este tipo.
Por último, como no hemos usado la palabra decremento, se asume entonces que incrementamos de 1 en 1 el valor de la variable Contador.
¿Y cómo se hubiera hecho esto usando decrementos? Pues, por ejemplo, así:
Declaración de variables
ENTEROS: Contador
fin Declaración variables

inicio

desde Contador<-300.000.000 hasta Contador=1 , decrementar, hacer
mostrar por pantalla 'Prometo ser bueno O:-)'
fin desde

fin
Aunque yo lo he hecho aquí por estar manejando variables de tipo entero, debo decir que es PELIGROSO usar una comparación de IGUALDAD entre dos números cualesquiera, y que, para evitar que por truncamientos, redondeos o algún otro motivo que lleve a pérdidas de decimales en los números, en vez de poner = es mejor poner <= o >=. Así, en nuestros dos ejemplos de bucle mientras, la línea "decisoria" en el bucle (por llamarla de alguna manera) es más recomendable escribirla así:
desde Contador<-1 mientras Contador<=300.000.000 hacer
o así, en el caso del decremento:
desde Contador<-300.000.000 mientras Contador>=1 , decrementar, hacer
Y con esto queda terminado el capítulo de las estructuras básicas para escribir nuestros algoritmos.
Notar que aquí he cambiado la palabra hasta por la palabra mientras. Lo que quiere decir es que, mientras que Contador sea menor o igual que 300.000.000, seguiremos dentro del bucle.
"Ah, no, con la paliza que nos has dado, ahora la que no se escapa eres tú. A ver, ¿y qué hay de esas variables llamadas 'acumuladores' que has mencionado antes y que no has usado para nada?"
Bueno, este... ¡me alegro de que me haga esa pregunta! :-D
Voy a poner un ejemplo de un acumulador para que se vea claro para qué sirven. Suponed, por ejemplo, que quiero sumar los primeros 10 números naturales. Una posible solución sería esta:
Declaración de variables
ENTEROS: i,acum
fin declaración variables

inicio

acum<-0
desde i<-1 hasta i<=10 hacer
acum<-acum+i
fin desde

mostrar por pantalla acum
fin
Probad a seguirle la pista al bucle, y decidme qué sale. ¿Lo sabríais escribir usando las otras dos estructuras repetitivas vistas hoy? Si es así, hacedlo }:-)
En el primer paso del bucle, acum vale 0, y le sumamos lo que vale i, que es 1. Vale, ahora acum vale 1. Se incrementa i y volvemos al cuerpo del bucle. Sumamos a acum lo que vale i. Ahora acum vale 1, e i vale 2; tras la suma, acum vale 3.
A eso es a lo que me refería antes, unas cuantas (pero cuántas) líneas atrás, cuando decía eso de "ACUMULADOR, cuya misión es almacenar una cantidad variable resultante de operaciones sucesivas y repetidas. Es como un contador, con la diferencia que el incremento/decremento es variable".
A diferencia de nuestro ejemplo REAL, en el que el incremento era siempre 1, aquí el incremento primero es 1, luego 2, luego 3... espero que con este ejemplo quede más claro, y si no, me pedís que ponga otro, y otro... hasta que lo entendais.
Otra nota (no sé cuántas llevo): podemos anidar los bucles. Esto es: dentro de un bucle, podemos ejecutar otro bucle, con la condición de que ese otro bucle esté COMPLETAMENTE CONTENIDO dentro del primero, si no, el algoritmo no es válido.
Por ejemplo: El caso más típico de bucle anidado es querer asignar valores a una matriz. Quien no sepa qué es una matriz, que espere al capítulo 7 del curso. Supongamos que nuestra matriz tiene por dimensiones 10 y 12, y queremos asignar valores a cada una de sus componentes. Esto lo haremos así:
Declaración de variables
A: Matriz(1..10,1..12) de ENTEROS
ENTEROS: i,j {variables para recorrer la matriz}
Fin declaración de variables

Inicio

desde i<-1 hasta i<=10 hacer
desde j<-1 hasta j<=12 hacer
A(i,j)<-i+j
fin desde {j}
fin desde {i}

Fin
Como veis, el bucle que gobierna la variable j está totalmente contenido dentro del bucle gobernado por la variable i, y, por cada iteración del bucle que dirige i, se ejecutan las 12 repeticiones del bucle dirigido por j. ¿Quién me dice cómo quedará nuestra matriz tras la asignación de valores que hemos hecho? Para no marearos, tomar las filas con la i, y las columnas con la j, como es usual en la notación de matrices.
Vamos ahora a por lo que a mí me gusta... los ejercicios };-D
1. Suponed que teneis un vector de 20 componentes (ver el capítulo 7 del curso). Escribid un algoritmo que lo invierta, es decir, la componente 1 pasa a ser la 20, la 2 pasa a ser la 19, la 3 será la 18... y así con todas.
2. Escribid un algoritmo que muestre por pantalla las tablas de multiplicar del 1 al 10. PISTA: Usad bucles anidados.
3. Escribid un algoritmo que muestre por pantalla la suma de los cuadrados de los N primeros números.
4. Escribid un algoritmo que calcule la media aritmética de una serie de N números.
Eso es todo (ahora sí), nos vemos en la próxima entrega, en la que hablaremos de... FUNCIONES Y PROCEDIMIENTOS.

Funciones y Procedimientos
Funciones
¿Qué es una función? Matemáticamente, una función no es más que una aplicación, esto es, una REGLA o CRITERIO para obtener un cierto resultado a partir de unos valores ya existentes. Este concepto se ha trasladado así al campo de la informática, aunque conviene matizar un poco más la idea.
La idea de función es la de una "caja negra" en la que nosotros metemos datos, dentro de esa "caja" pasa *algo*, y entonces, de la "caja", sale un resultado, un "producto".
Qué pasa dentro de esa "caja negra" depende; si somos nosotros quienes hemos de programarla, lo sabremos, pero si no, no tenemos por qué. Para poder usar la función sólo necesitaremos saber qué datos de entrada admite, y de qué tipo será el resultado. Hay que remarcar un detalle importante: las funciones devuelven un UNICO VALOR.
Por ejemplo; dentro de un programa, podemos querer calcular la media aritmética de una serie de datos. En principio, nosotros lo escribimos cuando tenemos que hacer los cálculos. Pero ahora, resulta que más adelante tenemos que volver a calcular la media aritmética de otros datos. Y más adelante, otra vez. ¿Vamos a escribir el código tantas veces? ¿No sería más lógico definirnos una función que se encargara de esa parte, y llamarla cuando la necesitemos?
Muy bien... ¿y cómo definimos una función? Pues de la siguiente manera:
funcion NOMBRE (arg1,...,argN) : TIPO
variables
......... {se declaran}

accion1
.......
accionN
Resultado <- Valor
fin funcion
TIPO es el tipo de dato que devolverá la función al terminar de hacer su trabajo. NOMBRE es el nombre que le vamos a dar a la función; por ejemplo, nuestra función se puede llamar Pepe o se puede llamar Media_Aritmetica. arg1 ... argN es la lista de parámetros que vamos a pasar a la función. La sección "variables" es una sección donde se declararán las variables a usar por la función. Más adelante hablaré del ámbito de las variables, para que se entienda el por qué de esto.
accion1 ... accionN es toda la faena que debe hacer la funcion. Al final de esa faena, la función devuelve un Resultado, que es el que hemos especificado como "Valor". ¿Y a dónde va a parar ese "Valor"? Bueno, es que para poder usar una función, tenemos que *invocarla*, llamarla de alguna manera. Si las funciones son cajas que devuelven valores, tendremos que disponer algún sitio para meter ese valor que nos devuelva la función.
¿Cómo la llamamos?
Para poder llamar a una función, tendremos que tener definida en nuestra declaración de variables una variable del MISMO tipo que devuelva la función. Entonces, lo que hacemos es asignar a esa variable lo que nos devuelva la función, haciendo lo siguiente:
Variable <- Nombre_Funcion(arg1, ..., argN)
Esta línea hace lo siguiente: llama a la función Nombre_Funcion, pasándole los parámetros arg1, ..., argN; entonces, se ejecuta el código de la función, hasta que llega al final, momento en que devuelve un valor, y este valor devuelto es asignado a la variable Variable.
Vamos a ver un ejemplo. Supongamos que queremos hacer un programa que calcule, en varios puntos, la suma de los N primeros números naturales, pero este N varía conforme el programa lo necesita. Queremos hacer una función que nos simplifique el trabajo. ¿Cómo lo hacemos? Bueno, lo primero que hay que plantearse siempre es qué parámetros necesita la función para trabajar, qué tipo de valor va a devolver y, por último, cómo va a hacer lo que tenga que hacer la función.
En nuestro caso, la función sólo necesita saber quién es N, que será de tipo entero; como la suma de naturales es natural, el resultado a devolver también tendrá que ser una variable de tipo entero. Falta ver cómo implementamos esa función. Por ejemplo, lo podemos hacer así (no voy a entrar ahora en mejoras):
funcion Suma_N_Naturales(ENTERO N) : ENTERO
variables
ENTERO: Suma,i

Suma <- 0
desde i<-1 hasta i=N hacer
Suma <- Suma+i

Resultado <- Suma
fin funcion
y ahora, vamos a usarla. En nuestro programa podemos poner:
Declaracion variables
ENTEROS: N, Suma
fin declaracion variables

inicio

desde N=1 hasta N=200 hacer
Suma <- Suma_N_Naturales(N);
mostrar por pantalla ('La suma de los ',N,' primeros naturales es ',Suma)
fin desde

fin
Con esto, hacemos 200 veces, incrementando en 1 cada vez N, la asignación a la variable Suma del resultado obtenido por la función Suma_N_Naturales, y mostrando por pantalla el resultado. Cada vez que se llegue a la línea de la asignación, se llamará a la función Suma_N_Naturales, se ejecutará el código de esa función, y al devolver el resultado, el programa principal recupera el control de la ejecución.
Sin embargo, dentro de la función tenemos declarada una variable que se llama Suma, y en el programa principal hay otra variable que se llama Suma... ¿cómo sabemos cuál es la buena? ¿no se mezclan ni nada parecido los valores?
Bueno, creo que este es un buen momento para hablar de...
Ámbito de las variables
Como ya hemos visto, un programa no tiene por qué estar formado por un único módulo (vamos a llamarle así) principal, si no que puede estar formado por muchas funciones, y por muchos procedimientos (de los que hablaremos más adelante). Cada función, o cada procedimiento, puede tener, dentro de su sección de declaración de variables, sus propias variables, aunque se llamen igual que las de la función de más arriba, puesto que, al declarar una función o un procedimiento, las variables que usan son LOCALES a ellos, es decir, sólo ellos saben que existen y, por tanto, pueden usarlas.
Como contraposición a las variables locales, tenemos las GLOBALES, que se declaran en una sección VARIABLES GLOBALES; estas variables son reconocidas por cualquier función o procedimiento que exista en nuestro programa, cualquiera puede modificar su valor en cualquier momento.
Ahora, ¿y si hay una variable global que tiene el mismo nombre que una variable local en una función que estoy usando? En ese caso, se usa la variable que es local a la función.
En nuestro ejemplo no se da este conflicto, al no haber una sección de variables globales (eso implica que no las hay), ya que cada variable Suma pertenece a una función distinta.
Algunas notas respecto al tema de funciones:
Es una buena costumbre escribir, justo antes de la definición de la función, un comentario sobre qué hace la función, para qué nos van a servir los parámetros que vamos a pasarle, y qué es lo que devuelve.
Hay que distinguir entre lo que se llama parámetros FORMALES y parámetros ACTUALES.
Cuando definimos una función, en su CABECERA (la línea donde pone su nombre, los argumentos que recibe y el tipo de valor que devuelve) aparecen nombrados los argumentos. El nombre que ponemos en ese momento es lo que se llama parámetros formales. Pero, cuando la llamamos, por ejemplo, Suma_N_Naturales(27), le estamos pasando el parámetro concreto 27: a estos parámetros se les llama parámetros actuales.
Como ejercicio, escribid una función que devuelva el resultado de:

siendo x un número real y n un número natural.
Procedimientos
Se llama así a un subprograma que ejecuta unas ciertas acciones sin que valor alguno de retorno esté asociado a su nombre. En otras palabras: NO devuelven valores (en cierto sentido).
Los procedimientos son normalmente llamados desde el algoritmo principal mediante su nombre y una lista de parámetros actuales (como las funciones) a través de una instrucción específica:
LLAMAR (CALL, en inglés)
Se diferencian de las funciones en que los parámetros de llamada pueden ser modificados si así se especifica dentro del procedimiento; en ese sentido se puede interpretar como que devuelven valores.
La forma de declararlos es la siguiente:
PROCEDIMIENTO Nombre (Lista de parámetros formales)
variables

acción1
.......
acciónN
Fin Procedimiento
y la forma de usarlos:
LLAMAR_A Nombre(Lista de parámetros actuales)
Vamos a ver un ejemplo de todo esto: queremos tener una forma de calcular la suma, la resta, el producto y el cociente de dos números cualesquiera. Obviamente, vamos a necesitar 6 variables; 2 de ellas serán los factores, y las otras 4, el resultado de las correspondientes operaciones. Podríamos pensar en 4 funciones que devolvieran cada una de ellas un número (entero, real, ...), pero podemos hacer esto de forma más compacta con un procedimiento. Veamos cómo lo declararíamos:
PROCEDIMIENTO Cuentas(ENTERO a, ENTERO b, ENTERO sum, ENTERO dif,
ENTERO mul, ENTERO dif)

sum <- a+b
dif <- a-b
mul <- a*b
div <- a/b

Fin Procedimiento
y luego lo podríamos llamar así:
LLAMAR_A Cuentas(5, 3, SUMA, RESTA, MULT, DIV)
con lo que a las variables SUMA, RESTA, MULT, DIV les serían asignados sus correspondientes valores; estas variables se supone que ya están declaradas previamente.
Y llegamos al último punto de esta entrega:
Recursividad
Una buena definición de este concepto es la siguiente.
Recursivo: ver recursivo
... :-D ... O:-)
Aunque, si lo quereis de otra forma: propiedad de una función o de un subprograma de llamarse a sí mismo.
Ilustremos esto con un ejemplo, nuestra función para sumar los N primeros números naturales. Vamos a escribirla de esta otra forma:
funcion Suma_N_Naturales(ENTERO N) : ENTERO
variables
ENTERO: Suma

si (N=1) entonces
Suma <- 1
si no
Suma <- N+Suma_N_Naturales(N-1)
fin si

Resultado <- Suma
fin funcion
Y vamos a llamarla con Suma_N_Naturales(4), detallando los pasos:

si (4=1) {falso, no se ejecuta}
si no {cierto, se ejecuta}
Suma <- 4+Suma_N_Naturales(4-1) {4-1=3}
Entramos en Suma_N_Naturales(3):

si (3=1) {falso, no se ejecuta}
si no {cierto, se ejecuta}
Suma <- 3+Suma_N_Naturales(3-1) {3-1=2}
Entramos en Suma_N_Naturales(2):

si (2=1) {falso, no se ejecuta}
si no {cierto, se ejecuta}
Suma <- 2+Suma_N_Naturales(2-1) {2-1=1}
Entramos en Suma_N_Naturales(1):
si (1=1) entonces Suma <- 1
y se devuelve el control al punto donde se llamó a Suma_N_Naturales(2), donde tenemos Suma <- 2+1, con lo que se devuelve el control al punto donde se llamó a Suma_N_Naturales(3), teniendo Suma<-3+(2+1), momento en el que se devuelve el control al punto donde se llamó a Suma_N_Naturales(4), donde tenemos Suma <- 4+(3+(2+1)), justo el resultado esperado.

Punteros; esos desconocidos
Antes de explicar qué son, para qué sirven y cómo hacer uso de ellos, vamos primero a exponer unas cuantas consideraciones:
Los punteros no están disponibles en todos los lenguajes de programación, ello significa que si, por ejemplo, programais en C, podeis utilizarlos, pero si programais en Basic no.
Su uso produce unas ciertas ventajas sobre los programas, y es que aumentan la flexibilidad a la hora de, por ejemplo, declarar vectores o matrices cuyo tamaño no sea predefinido. No acaban ahí las ventajas, con estructuras de datos más complejas son el pan nuestro de cada día, pero de todo eso ya hablaremos.
Sin embargo, no todo es maravilloso, y tienen serios inconvenientes que provocan más de un quebradero de cabeza. Es muy fácil equivocarse usándolos y con ello escribir en alguna zona de memoria no aconsejable (como las reservadas por el sistema operativo), lo que provoca el consiguiente cuelgue en sistemas poco robustos que permitan escribir en cualquier parte. No hay nada más peligroso que un puntero incontrolado o sin inicializar.
Vistas las pegas (ya las descubrireis cuando el programa se os cuelgue sin motivo aparente), vamos a ver qué es eso de los punteros, pues parece que tenemos que tenerles un cierto respeto :-D
avatar
HERNAN DARIO RODRIGUEZ

Mensajes : 14
Puntos : 45
Fecha de inscripción : 04/08/2010
Edad : 35
Localización : cali

Ver perfil de usuario

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

 
Permisos de este foro:
No puedes responder a temas en este foro.