Calcula qué años son bisiestos y cuáles no con Scratch

años bisiestos con scratch

En esta entrada volveré a explicar cómo realizar un programa con Scratch. En este caso, cómo saber si un año es bisiesto o no. Sé que puede no ser muy glamoroso pero es un excelente ejercicio que se usa siempre para aprender a programar y que permite explicar temas tan importantes como son los algoritmos y las expresiones lógicas.

Si no conoces Scratch, te recomiendo el artículo de introducción: Scratch, programación para chicos.

Ten en cuenta que ya he realizado otros programas en Scratch en Mentes Liberadas

Recuerda que la resolución del problema que planteo en este artículo y en todos es solamente una de muchas posibles. Se puede hacer de otra forma y se puede mejorar. Esta es, simplemente, la que se me ocurrió a mí porque es didáctica. Los programadores solemos resolver el problema de un año bisiesto en una línea de código. No es la idea hacer eso aquí.

En este enlace tienes acceso al programa que haremos terminado y funcionando.

Por último, por si no has leído los artículos anteriores, te cuento que soy programador y que he trabajado en empresas de informática como desarrollador, líder técnico, líder de proyectos y project manager. Una de mis principales responsabilidades era la formación de programadores jóvenes. Me apasiona explicar temas de programación y trato de hacerlo con todo el detalle posible.

Ahora, sí, vamos con el programa.

El programa que vamos a hacer

El programa que vamos a hacer lo bauticé Mago de los años bisiestos. ¿Por qué? Bueno, porque el personaje principal es una especie de mago (o brujo) y lo que hace es “adivinar” si un año fue, es o será bisiesto.

En realidad, no hace falta poner a un personaje a decir esto, pero vamos a hacerlo más divertido porque después de todo, admitámoslo, no es tan alucinante saber si un año es bisiesto o no.

¡Ah! Pero olvidé mencionarlo… ¿Sabes qué es un año bisiesto?

Quizás no. Y aunque lo sepas, mejor si lo aclaramos.

Los años bisiestos

Saber qué es un año bisiesto es fácil. Un año es bisiesto si en febrero tiene 29 días en vez de 28.

La pregunta que seguramente te estarás haciendo es ¿por qué cada tanto tenemos un año bisiesto? ¿Es un capricho de alguien? ¿Es aleatorio? ¿Quién lo inventó?

La razón de que existan años bisiestos

Un año es el tiempo en el que nuestro planeta Tierra da una vuelta completa a la órbita alrededor del Sol. Muchos creen que esa vuelta demora 365 días exactos.

Eso es en realidad impreciso. La Tierra tarda 365 días, 5 horas, 48 minutos y 45,10 segundos en darle la vuelta al Sol. Por lo tanto, si se contaran sólo 365 días exactos, con el tiempo empezaría a haber un desfasaje, que al principio sería pequeño pero con el correr de los años y de los siglos, sería enorme.

El calendario juliano

Como la diferencia por año es de casi 6 horas, lo que hicieron los romanos inicialmente fue agregar un día extra cada cuatro años para compensar y así crearon el calendario juliano. ¡Y listo el asunto! Qué inteligentes que son los romanos…

Mhhh… ¿listo el asunto realmente?

¡No! Claro que no. El desfasaje por año es de CASI 6 horas, pero no llega a serlo. De esta forma habría un desfasaje al revés. Es decir, hacia adelante. ¿De cuánto? Pues, de 11,25 minutos.

¡Ah, pero no es tanto!

No es tanto en un año, pero a lo largo de 500 años, produciría un desfasaje de… ¡4 días!

El calendario gregoriano

Para solucionar este problema de 4 días de desfasaje, en el año 1582, el papa Gregorio XIII promovió el nuevo calendario que luego se pasaría a llamar calendario gregoriano, que es el que usamos actualmente.

¿La solución al problema de los 4 días de adelanto cada 500 años?

Agregar una regla que mantenga lo de agregar un día cada 4 años, pero con algunas excepciones. Si el año termina en 00, no es bisiesto. Pero si es divisible por 400 sí.

¿Parece complejo? Puede serlo un poco.

¿Esto resolvió el problema del desfasaje? Digamos que sí. En realidad, cada año, nos adelantamos unos 30 segundos. Esto implica que dentro de más de 3000 años habría que hacer un ajuste. Pero todo esto es incluso más complejo dado que la Tierra no mantiene siempre su misma aceleración y hay otros factores astronómicos que influyen.

Digamos que con esta regla tenemos el problema solucionado. Al menos, para lo que nos interesa.

Entonces... ¿cuándo un año es bisiesto?

Lo que queremos que haga nuestro programa es que determine si un año es bisiesto o no. Por lo tanto, la pregunta que nos haremos es: ¿Cuándo un año es bisiesto?

Hay muchas maneras de formular la regla, pero a mí me gusta la siguiente:

Un año es bisiesto si es divisible por 4 y no es divisible por 100, salvo que, en este último caso, sea divisible por 400.

Nuestra principal tarea en este programa que haremos es traducir esa frase a lenguaje de programación. En lógica se acostumbra a hablar de formalización cuando convertimos una frase en un conjunto de símbolos que representen una expresión. Bueno, algo así haremos.

Ahora sí, pasemos a Scratch.

El mago de los años bisiestos

El objetivo

Llegó el momento de programar, pero primero, como digo siempre, hay que establecer un objetivo bien claro. ¿Qué queremos que haga nuestro programa? A veces alcanza con tener esto en nuestra mente. Otras veces es mejor escribirlo, especialmente si trabajamos en equipo.

En este caso, quiero que al comenzar el programa aparezca un personaje que pida al usuario a través del sistema de diálogos de Scratch que ingrese un año, o mejor dicho, un número que represente un año.

No habrá ningún tipo de validación. Esto quiere decir que no vamos a ver si lo que introduce el usuario es un número o no. Vamos a confiar en que hará lo que le pedimos (en la vida real nunca es así, siempre hay que validar todo).

Una vez que el usuario ingresa el número, nuestro programa chequeará si el año es bisiesto o no y responderá a través del sistema de diálogos de Scratch.

Finalmente, dejaremos abierta la posibilidad para que el usuario vuelva a introducir otro año si presiona cualquier tecla.

El personaje principal

Comenzaremos por el principio. Vamos a la librería de Scratch y buscamos algún simpático personaje que será quien le pedirá al usuario que inserte un número y le dirá si el año es bisiesto o no.

En mi caso, decidí utilizar el llamado Ghoul y le dejé ese nombre porque en esta ocasión no es tan importante qué nombre llega.

Puedes ubicar a tu personaje donde quieras dentro del área del juego.

Una vez ubicado, debemos seleccionar el objeto para comenzar a armar su programa.

El programa

Inicio y estructura del programa

El programa debe iniciarse con la bandera, como todos los programas de Scratch.

Luego, lo que necesitaremos será un bloque Por siempre dentro de los bloques de control, ya que el usuario podrá preguntar todas las veces que quiera si un año es bisiesto o no.

Lo siguiente que necesitamos es que nuestro personaje le pida al usuario que ingrese un número. Eso lo logramos con un bloque de preguntar y esperar. Este tipo de bloque lo encuentras en los Sensores. En el campo de texto escribe algo así como: “Dime un año y te diré si fue o si va a ser bisiesto”.

De esta forma, nuestro programa debe ir quedando así hasta el momento:

El algoritmo

Luego, habría que utilizar uno o varios bloques condicionales que muestren un mensaje u otro según si el año introducido es bisiesto o no. Voy a agregar un bloque de estos de forma simbólica por ahora pero no voy a completar la expresión ni meterme dentro de ese bloque.

Dejaré eso para más adelante. Lo importante es entender que en ese bloque (o dentro) se define por sí o por no si un año es bisiesto.

Por lo tanto, en base a esa respuesta, podemos seguir haciendo el programa y dejar para después el algoritmo del año bisiesto.

La repetición pausada

Como nos propusimos en el ejemplo, al final del programa, si el usuario presiona cualquier tecla, entonces todo debería volver a comenzar. Para hacer esto, vamos a utilizar un bloque esperar hasta que, de los bloques de control.

Dentro le pondremos un bloque de tecla presionada. Este lo encuentras en Sensores. Le tendrás que seleccionar cualquiera.

Cuando los juntas, deben quedar así:

Ahora solo resta insertar este bloque en el resto del programa. ¿Dónde debería encajar? Tiene que estar luego de la condición y antes de que el programa se comience a repetir.

El algoritmo

Un año es bisiesto si es divisible por 4 y no es divisible por 100, salvo que, en este último caso, sea divisible por 400.

Parece una expresión larga y confusa, ¿no crees? Un problema demasiado grande.

Pero no te preocupes. Te voy a develar un gran secreto de los programadores. A nosotros no nos asustan los problemas grandes. Lo que hacemos cuando nos encontramos con un problema así es dividirlo en partes.

Entonces, pensemos cada caso de lo que dice la frase por separado.

  • Es divisible por 4
  • No es divisible por 100
  • Es divisible por 400

Si combinamos estas tres partes, podremos llegar a saber lo que necesitamos:

Primero, tenemos que saber si es divisible por 4. Si no es divisible por 4, entonces no es bisiesto. ¡Adios!

Si es divisible por 4, entonces tenemos que ver si es divisible por 100. Si no es divisible por 100 entonces sí es bisiesto. ¡Excelente!.

Ahora, si es divisible por 4 y también es divisible por 100, faltaría ver si es divisible por 400. Si lo es, entonces es bisiesto y si no lo es, entonces no.

Y esto que tenemos escrito arriba es nuestro algoritmo en pseudocódigo (una especie de código de programación informal), solo que está en palabras y tenemos que traducirlo a código de programación de Scratch, es decir, a bloques.

Pero antes de hacer eso, ¿te has preguntado cómo saber si un número es divisible por otro en Scratch?

Hemos hecho todo hasta acá, menos lo más importante. A partir de aquí hay dos caminos.

  1. Armar una única expresión lógica que determine si un año es bisiesto. Se puede hacer pero no sería muy didáctico.
  2. Armar un algoritmo que involucre varios bloques condicionales y que determine si un año es bisiesto o no. Eso haremos a continuación.

Tenemos que armar un algoritmo que defina si el año que introduce el usuario es bisiesto o no.

En Sensores encontrarás la variable que tenemos que usar, que tiene el valor insertado por el usuario y se llama: respuesta. La usaremos en distintos bloques.

Volvamos a la frase que define si un año es bisiesto o no:

El operador mod

Te voy a presentar el operador módulo. Así como está la suma, la resta, la multiplicación y la división, también tenemos a… ¡mód!. Mod o mód es el nombre común que le damos al operador módulo.

¿Y qué hace? ¡Qué no hace! El operador mod se queda siempre con el resto de una división.

Lo explicaré mejor con un ejemplo. Si hacemos 5 Mod 3, el resultado es 2. Porque es el resto de hacer 5 dividido 3. Si hacemos 28 Mod 9, el resultado es 1 porque 28 / 9 es 3 y el resto, 1.

¿Y qué tiene que ver esto con que algo sea divisible?

Un número es divisible por otro si el resto es 0. Por ejemplo, 20 dividido 5 es 4, y el resto es 0. Entonces, decimos que 20 es divisible por 5. Estamos hablando siempre de números enteros.

Por lo tanto, el operador módulo es una herramienta que sirve para saber si un número es múltiplo de otro.

El algoritmo con bloques de Scratch: El primer condicional.

Bien, olvidémonos del resto del programa y concentrémonos en el algoritmo. Los programadores hacemos mucho eso. Lo llamamos abstracción.

Lo primero que vamos a necesitar es un bloque Si… entonces con si no. Este lo encontramos en Control.

Lo siguiente que tenemos que hacer es armar la expresión que va en ese bloque. La frase decía “Si es divisible por 4”, lo que traducido es un Año Mod 4. El valor del año lo sacamos de la variable respuesta. Usaremos un bloque mód de Operadores y le pondremos respuesta en el operando de la izquierda.

Y eso debe ir en un bloque de comparación de igualdad. Este bloque también se encuentra en Operadores. Le ponemos un 0 en el operando de la derecha.

Luego, juntamos todo y tenemos la condición de si el año introducido es divisible por 4.

Esto lo insertamos en el bloque condicional si.

Como habíamos dicho al comienzo, si el año no es múltiplo de 4… entonces NO es bisiesto. Así que ya podemos hacer que nuestro personaje diga su veredicto para ese caso.

Buscamos un bloque decir, de esos que están en apariencia y le ponemos “No, el año no es bisiesto”.

Este bloque lo ponemos en el caso del si no:

El segundo condicional

Hasta aquí tenemos una parte del algoritmo. Si el año introducido no es múltiplo de 4, entonces ya sabemos que no es bisiesto. Pero, ¿qué ocurre si es múltiplo de 4?

En ese caso, lo que habría que comprobar es si el número que representa al año es múltiplo de 100.

Buscamos un bloque si… entonces con si no…

Y utilizamos un bloque de operador mód con un bloque de comparación de igualdad. Al bloque mód le ponemos la variable respuesta en el operando de la izquierda, y en el de la derecha, 100. Al operador de igualdad, le ponemos un 0 en la derecha.

Juntamos ambos y ya tenemos la segunda expresión que necesitamos:

La ponemos en el bloque si… entonces.

Para no perder de vista lo que estamos haciendo, pongamos este bloque donde corresponde: en el caso positivo de que el año sea divisible por 4.

Si volvemos a la frase veremos que si un año es divisible por 4 y no es divisible por 100, entonces es bisiesto. Entonces completemos con otro bloque decir que en este caso debe tener el texto: “Sí, el año es bisiesto”.

Hemos adelantado mucho. Solo falta el caso en el que el número es divisible por 4 y también por 100. Ahí entra en juego si es divisible por 400. Pasemos, entonces, al tercer condicional.

El tercer condicional

La idea aquí es la misma así que no voy a repetir todos los pasos. Se necesita un bloque operador mód, al que hay que ponerle la variable en el operando de la izquierda y un 400 en el operando de la derecha. Estos se deben incluir en un bloque de comparación de igualdad con un cero del lado de la derecha. Todo esto, lo montaremos sobre un bloque si… entonces con si no.

Esto lo vamos a incorporar al programa que tenemos hasta aquí.

Ya sabemos que el año es divisible por 4 y también por 100. Entonces, se define en este condicional. Si es divisible por 400 es año bisiesto. Y si no, no.

Agregamos los bloques decir que corresponden a cada caso y el algoritmo nos queda así finalmente.

Juntando el algoritmo con el programa

Llegó el momento de juntar las dos partes del programa que tenemos. El principio y la estructura principal del programa junto con el algoritmo.

El algoritmo debe ir entre la pregunta y la espera de presionar una tecla por parte del usuario.

Probando el programa

Solo resta probar el programa. Cuando presionamos la bandera verde de Scratch. Lo puedes probar de forma interactiva en este enlace.

Por ejemplo, con el año 2000.

Obtenemos la siguiente respuesta:

El camino alternativo​

En un momento te comenté que había otra alternativa a armar el algoritmo que utilizamos. Esta alternativa consiste en armar una expresión lógica utilizando muchos bloques Y y O. Así quedaría el programa en ese caso:

El programa es más corto. Pero la solución es más difícil de visualizar. ¿Eres capaz de entender de un vistazo lo que ocurre en ese único condicional?

Los programadores muchas veces tenemos que tomar decisiones entre hacer un código que se pueda entender, contra otro que sea complicado pero quizás más corto o eficiente.

Según el caso convendrá uno u otro, aunque hay una corriente que apoyo que dice que lo más importante es que el código se entienda. Debe entenderse para uno mismo y para otros programadores.

Conclusiones

Estamos llegando al final de este extenso artículo. Como siempre, quiero que nos detengamos a pensar algunos aspectos de lo que estuvimos haciendo. Es importante reflexionar sobre lo que hicimos y de esa forma aprender conceptos fundamentales.

Historias de usuario o casos de uso

Cuando me puse el objetivo de lo que el programa tenía que hacer y lo describí en detalle usando mis palabras, lo que hice en realidad fue crear una historia de usuario o un caso de uso.

Las historias de usuario describen en un lenguaje fácil que todos entienden lo que tiene que ocurrir con el programa. Las puede crear un programador, un analista de sistemas o en organizaciones más modernas, el product owner, que es la persona que comprende lo que el programa debe hacer. La historia de usuario es en lo que se basa el programador para luego dar su solución codificada.

Los casos de uso son similares a las historias de usuario, pero están más detallados y son más estrictos. En realidad, están quedando en desuso. Las historias de usuario han demostrado ser mejores.

Dividir problemas grandes en problemas más pequeños

Como has visto en este ejemplo, cuando aparece un problema muy grande no hay que asustarse ni frustrarse. Todos los problemas grandes se pueden descomponer en problemas más pequeños. Y esos a su vez, también se pueden descomponer en problemas todavía más simples.

De esta manera, lo que haremos siempre es resolver los problemas más pequeños y así, iremos subiendo en complejidad hasta resolver el gran problema que apareció en primer lugar.

El operador módulo

El operador módulo tiene distintas aplicaciones en programación y se suele usar bastante. Es bueno conocerlo y saber que es una herramienta más que se puede usar en cualquier momento y no algo exótico a lo que hay que tenerle miedo.

Concentrarse en una parte del código

En algunos momentos los programadores decidimos abstraernos del contexto de un programa y nos centramos en la resolución de un problema en particular. Justamente, como te comenté en el medio del artículo, se llama abstracción.

Es un gran recurso que permite crear módulos de programación que repitan tareas y también es realmente útil para trabajar en equipo.

Claridad del código por sobre eficiencia

Al final del artículo te mostré la posible solución alternativa. Pudiste ver que era más compleja a simple vista, pero hacía el programa mucho más corto. Este tipo de decisiones es común y ahora que estás aprendiendo a programar te voy a recomendar siempre que optes por la solución que mejor entiendas.

En un tiempo, cuando seas un gran programador, o una gran programadora, sabrás qué decisiones tomar.

Para cerrar

Y este es finalmente el fin del artículo. Me ha llevado varias horas escribirlo y otras tantas revisarlo. Si te ha resultado interesante o conoces a alguien que le pueda ser de utilidad, por favor compártelo.

Si te ha gustado mucho y te gustaría que siga escribiendo sobre Scratch, por favor házmelo saber. Déjame un comentario al final del artículo. A veces dudo de si realmente hay alguien ahí leyendo este tipo de artículos.

Eso es todo. Gracias por tu atención. Nos reencontramos la próxima.

Curso online de Scratch en Udemy

Si este artículo te gustó mucho y te dieron ganas de aprender mucho más, no dejes de inscribirte al curso de Aprende a programar jugando con Scratch de Udemy. Un curso online que cuenta con casi doce horas de video y 74 clases en total.

Un curso práctico donde se programan videojuegos y se va aprendiendo en el momento. De utilidad para estudiantes y también para docentes que quieran aprender Scratch.

Curso de Scratch en Udemy

2 comentarios
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Quizás también te interese