Estamos en un proceso de migración de contenidos desde el sitio scratchbydsigno.com.ar hacia este nuevo blog.

La prioridad está centrada en los 3 Tutoriales que constituyen la base de dicho sitio, para luego seguir con el resto de los contenidos.

En caso de que encuentres algún error de visualización, o links rotos, puedes comunicármelo usando el formulario de contacto...

1er paso: dibujar un cuadrado (parte V)

Te había dejado en la página anterior un "trabajito" —a homework dirían en las tierras del imperio—.
No es que intente evadir mi responsabilidad: es que en programación es importante desarrollar cierta capacidad de prever o anticipar por lo menos un camino de solución, antes incluso de garabatear en un papel alguna palabra o algún diagrama al respecto.
Si lo hiciste (además de una carita feliz en el cuaderno) te llevarás la posibilidad de contrastar tu solución con la aquí propuesta. Si bien nuestro intento de definir con precisión el problema va a acotar el universo de soluciones posibles, recordá que difícilmente exista algo así como un "camino único" para llegar a la meta, y que quizás a vos se te haya ocurrido una solución posible distinta a la que expondremos de aquí en adelante… es una de las cosas maravillosas del mundo Scratch.

Pensar > Escribir > Programar

Pensar un plan, escribir un algoritmo, traducir ese algoritmo (programar) : es la máxima síntesis a la que puedo llegar.
Habría que agregar que nos conviene seguir una estrategia, que es la de concentrarnos en el núcleo del problema dejando los detalles accesorios para una etapa posterior (esto es, bosquejar una solución antes que nada).

Pensar

Pensemos concentrándonos en lo principal: dibujar nuestro cuadrado con el tamaño y posición solicitado, y en el orden prescripto.
Como sabemos Pier irá dibujando a medida que se desplace, pero sólo si antes tiene habilitada su capacidad de dibujo (debe tener su lápiz abajo). Pero antes de ésto deberá haber borrado cualquier dibujo previo y estar posicionado en su punto de partida (?) apuntando en dirección 90º (a la derecha).
Se moverá 200 pasos, girará 90º en sentido horario, hará una pausa de 1 segundo para descansar, se moverá otros 200 pasos, girará otros 90º en sentido horario… ¿ya lo tenés?. Supongo que sí, porque es bastante simple.
El primer punto a dilucidar (vaya palabreja) es el del punto de inicio del dibujo: el único dato vinculado a esta cuestión es el pedido de que el cuadrado quede centrado respecto al escenario (remember that?).
En el fondo no es más que una cuestión de simetría. Como ya vimos (¿ya viste?) el sistema de coordenadas está centrado respecto al escenario, por lo que el cuadrado deberá quedar centrado respecto a este mismo sistema: equivale a decir que el centro del cuadrado debe tener coordenadas (0 , 0) [¡guauh!].
Como el cuadrado es de 200 x 200 pasos, la conclusión es que el susodicho punto deberá estar 100 pasos a la izquierda del eje y, y 100 pasos arriba del eje x. Sus coordenadas tendrán que ser (x= -100 , y= 100), y es desde ese punto que Pier deberá comenzar a dibujar. Es creer o reventar.
Va a quedar una cuestión más que resolver: en que orden lógico disponer los pasos previos a las instrucciones de dibujo… yo aprovecharía a agregar algo más en este momento: contemplar la posibilidad de "levantar" el lápiz como otra instrucción más a ser utilizada.
Pensemos. En principio no sabemos donde va a quedar parado Pier después de que hayamos "corrido" alguna vez el programa. Si le ordenamos que borre lo dibujado y después se mueva a las coordenadas de inicio ¡va a volver a dibujar mientras se mueve hasta llegar a ese lugar, porque tiene su lápiz abajo!.
Suele ser un buen recurso ponerse en el lugar del objeto a ser programado: bien pensado, en una situación de la "vida real" si yo fuera Pier levantaría el lápiz y lo bajaría sólo al momento de comenzar a dibujar.
Esto nos dá una pista del orden lógico con el cual ejecutar estas acciones: levantar el lápiz, borrar, moverse al punto de inicio y apuntar en la dirección requerida (90º), y por último bajar el lápiz: Pier estaría así en condiciones de comenzar a dibujar.

NOTA: si empiezo estas acciones con la de subir el lápiz y las culmino con la de bajar el lápiz, el orden de las instrucciones intermedias dejará de ser relevante (para nuestro problema).

Dedicar el suficiente tiempo a pensar un camino de solución siempre es una práctica recomendada. Es conveniente concentrarse solo en aquellos puntos que aparezcan como más relevantes para el problema. De cualquier manera lo más común es que al llevar toda esta "planificación previa" a la práctica aparezcan detalles o inconvenientes no previstos, que harán que tengas que reelaborar lo pensado en esta etapa… Don't worry about that! (no te preocupes por esto).

Escribir [un algoritmo]

Aunque ya hablamos algo sobre algoritmos, conviene en este momento dejar en claro una cosa: un algoritmo no es lo mismo que un programa.
De la escritura de un algoritmo "en un papel" —ya sea de un modo más verbalizado o por medio de diagramas— luego se debe pasar a su traducción usando algún lenguaje de programación (por ejemplo Scratch), dando como fruto un programa que pueda ser interpretado por nuestra computadora.
Ergo: un mismo algoritmo puede ser traducido a distintos lenguajes de programación.

NOTA sobre Scratch

Las características eminentemente gráficas de Scratch nos dan una enorme ventaja: posibilitan desarrollar y "escribir" los algoritmos al mismo tiempo que programamos, y también permiten ir probando las funcionalidades en tiempo real, sin necesidad de compilaciones ni traducciones desde el algoritmo en papel al programa propiamente dicho.
Pero Scratch nos dá la posibilidad de representar (no en un papel, sino en la pantalla) los algoritmos y de programar al mismo tiempo, por lo que no nos vamos a explayar demasiado sobre la escritura de algoritmos. De cualquier modo, no está de más mencionar algunas de sus formas de representación más usuales:
  • Descripción narrada.
  • Pseudocódigo.
  • Diagramas de flujo.
  • Diagramas NSD (Nassi-Shneiderman o de Chapin).
Dejo a tu consideración cómo quedaría la formulación de nuestro algoritmo usando una descripción narrada, muy útil si (como es en nuestro caso) tenemos un algoritmo de lo más simple.

Descripción narrada del algoritmo

  1. subir lápiz
  2. borrar todo
  3. ir a las coordenadas x= -100, y= 100
  4. apuntar en dirección 90º
  5. bajar lápiz
  6. mover 200 pasos
  7. girar 90º sentido horario
  8. esperar 1 segundo
  9. mover 200 pasos
  10. girar 90º sentido horario
  11. esperar 1 segundo
  12. mover 200 pasos
  13. girar 90º sentido horario
  14. esperar 1 segundo
  15. mover 200 pasos
  16. girar 90º sentido horario
  17. esperar 1 segundo
Recordemos que esta solución no toma en cuenta algunas cuestiones como ser el tamaño del lápiz y el cambio de colores del mismo al momento de dibujar cada lado del cuadrado —eso lo veremos directamente cuando realicemos el programa en Scratch—.
Cabe decir que, tal como notamos antes, al colocar como primera instrucción a subir lápiz el orden de las instrucciones 2, 3 y 4 puede ser intercambiado sin afectar significativamente el funcionamiento del programa: podemos considerar a esto como algo excepcional, ya que la conmutatividad no es una propiedad aplicable a los algoritmos (pero suele ser posible, por ejemplo, al momento de determinar las condiciones iniciales que va a tener un programa).
Ya habiendo dejado plasmado en el papel el fruto de nuestro pensamiento (¡que poético!) es momento de pasar a la acción…

Programar (¡al fin!)

No te voy a dar mucho la lata sobre programar (en esta página).
Ya sabés que tenés que abrir en Scratch el proyecto en que estuvimos trabajando, y como primera medida borrar el programita de prueba que usamos antes (clic derecho sobre los bloques… luego borrar).
A continuación tenés que reproducir el algoritmo al que llegamos (hasta ahora): te debería quedar algo como lo que ves en la imagen siguiente. NADA COMPLICADO (¡y no te olvides de guardarlo!).
algoritmo simple
Vamos a volver a destacar algo dicho: podríamos haber pasado directamente de la 1ª etapa (pensar) a la implementación del programa, ya que de alguna manera Scratch te permite escribir el algoritmo y el programa al mismo tiempo (perdón por la simplificación).
Si ya probaste el programa —supongo que sí, "tanta charla para ésto…"  habrás dicho— ya sabés que quedan cosas para hacer (el temita del lápiz, quizás achicar a nuestro "agrandado" Pier… vaya a saber que más se nos puede ocurrir).

Pero hay algo más… ¿no ves cosas que se repiten? ¿se podrá hacer algo con eso? ("ya empezó con las preguntitas el señor…")

Ya están a punto de sangrarme las yemas de los dos dedos que uso para escribir. Por obvias razones humanitarias nos vemos obligados a interrumpir este relato. Nos vemos después, esta vez para analizar nuestro nuevo programita… ¡no te vas a librar de mí tan facilmente!
Última actualización: Febrero 23, 2014

No hay comentarios.:

Publicar un comentario

© Scratch CodeLab | D153ñ0 b454d0 3n l4 pl4n71ll4 SimpleRWD d3 Oloblogger