Introducción a la Programación Sistemática – Semana 3

La semana 3 de Introducción al Diseño Sistemático de Programas fue definitivamente MUCHO más contenido de video de lo que estaba acostumbrado antes, y puedo decir con seguridad que habiendo comenzado a ver los videos de la semana 4, ¡solo se volverá más loco de aquí en adelante!

Así que la semana 3 de clase se centró principalmente en aprender a diseñar datos y te guiaré a través de cada lección que aprendimos paso a paso lo mejor que puedo. Curiosamente, también he descubierto que escribir estos resúmenes también me ayuda con mi propio aprendizaje, ¡así que espero que leerlos haga algo similar para aquellos de ustedes que son mis compañeros de clase!

Lección 1: Expresiones cond

En esta lección queda claro que el diseño de datos es un punto de apalancamiento en el diseño de programas. Esto se debe a que cuando cada uno de nosotros diseña los datos, estamos tomando, a sabiendas o sin saberlo, decisiones sobre cómo operarán todas las funciones que luego operan con esos datos.

Las expresiones condicionales, o expresiones cond, nos permiten programar el comportamiento condicional cuando hay dos o más casos. Esto permite que las expresiones cond se consideren "condicionales de varios brazos".

Plantilla de expresión cond estándar:

Para formar una expresión de control de calidad cond:

Donde la expresión 1 es la pregunta y la expresión 2 es la respuesta.

Uso de la plantilla de expresión cond para hacer un ejemplo de cond:

Las reglas para evaluar las condiciones son:

1. No Question/Answer pair? Signal an error.
2. Si la primera pregunta no es un valor, evalúela y reemplácela con su valor. Reemplace todo cond por un nuevo cond en el que la primera pregunta se reemplaza por su valor.
3. Si la primera pregunta es un valor booleano que se evalúa como verdadero, o es una instrucción que se evalúa como otra cosa, reemplace la condición completa con la primera respuesta.
4. Si la primera pregunta es falsa, quite el primer par de preguntas y respuestas y reemplácelo por una nueva condición que no tenga el primer par de preguntas y respuestas.
5. Dado que la ^1ª pregunta no es verdadera o falsa, señale un error.

Notas adicionales de esta lección:

[] son convenciones visuales: el Dr. Racket procesa ()s y []s de la misma manera, pero el uso de []s nos permite no sentirnos abrumados.

Lección 2: Definiciones de datos

En primer lugar, en esta lección, se explica que una definición de datos es un elemento de diseño. En cualquier programa, hay un dominio problemático, así como datos. Es el reino de los datos tomar la información que se encuentra dentro del dominio del problema y representarla con datos. Esencialmente, las definiciones de datos describen cómo representamos la información como datos en nuestro programa. Cuando estaba viendo el video de esta lección, realmente me recordó a una tecla de color que crearía en Excel: tomar un símbolo, o color, y definir lo que significa para el usuario, o en este caso, la computadora, para que pueda interpretar lo que el diseñador (yo) quiso decir.

A continuación, se muestra un ejemplo de una definición de datos de Dr. Racket:

Lesson 3: Atomic Non-Distinct Data Definitions

Esta lección proporciona un ejemplo directo de cómo funcionan las definiciones de datos en la práctica, utilizando la premisa de diseñar una definición de datos para representar el nombre de una ciudad.

Puntos para recordar:

1. Las partes de una definición de datos se encuentran en la lista de recetas
2. Existen diferentes tipos de definiciones de datos
3. Atómico significa que no se puede desarmar y hacer que aún conserve algún significado en el espectro de la información problemática.

Ejemplo de una definición de datos para atómicos no distintos:

;; CityName is String
;; interp the name of a city
(define CN1 “Boston”)
(define CN2 “Vancouver”)

Las plantillas basadas en datos se trataron a continuación en la lección, y para este mismo ejemplo, continuaríamos de la siguiente manera:

Lección 4: HtDF con definición de datos

El propósito de esta lección era enseñarnos cómo diseñar una función que consumiera datos no primitivos.

De esta lección, en realidad solo hay algunos consejos rápidos que obtuve y me gustaría compartir con ustedes:

1. En el caso de las expresiones booleanas, los predicados deben terminar en un ?
2. Al diseñar con la definición de datos, utilice los ejemplos como directrices.
3. Cuando una función tiene dos casos, desarrolle la plantilla ajustando una instrucción if alrededor de la plantilla
4. (Lo más importante!!) ¡No olvides comentar tu stub cuando comiences tu código!

Lección 5: HtDF X Estructura de la ortogonalidad de los datos

En primer lugar, cuando vi el título de esta lección, no tenía ni idea de qué iba a tratar: me enorgullezco de tener un vocabulario en inglés bastante decente, pero la ortogonalidad era un término completamente nuevo para mí. Para aquellos de ustedes que están en el mismo barco, permítanme explicar: Ortogonal simplemente significa "mayormente independiente". En este caso es importante porque el método HtDF está estructurado con la suposición de que los tipos de datos con los que está trabajando son ortogonales, por lo que a medida que aprendemos más tipos de datos podemos implementarlos en nuestras funciones previamente escritas sin error. No he probado esta teoría, eso sí, ¡pero eso es lo que entiendo que es en base a las lecciones proporcionadas aquí!

El resto de esta lección se basó en explicar este gráfico de tipos de datos, que creo que es bastante bueno:

Básicamente, este gráfico recorre todos los diferentes tipos de datos y nos prepara para las próximas lecciones que hablan sobre el intervalo, la enumeración y la desglose.

Lección 6: Definiciones de datos de intervalo

Las definiciones de datos de intervalo se utilizan cuando los números que se van a representar están dentro de un rango determinado. La clave para representar adecuadamente esto son los matices de inclusividad y exclusividad. Por ejemplo:

[1, 7] es inclusivo, lo que significa que los números incluidos en el intervalo son 1, 2, 3, 4, 5, 6, 7.

[1, 7], sin embargo, es excluyente, lo que significa que los números incluidos en este intervalo son 1, 2, 3, 4, 5, 5, 6.

A diferencia de las expresiones cond, en el caso de las definiciones de datos de intervalo, [] y () producen resultados diferentes.

Además, al usar definiciones de datos de intervalo, es importante utilizar las dos reglas siguientes:

1. Utilice el Gráfico de datos para encontrar la receta más adecuada. OPTA POR LO MÁS ESPECÍFICO.
2. Utilice la página Plantillas de definiciones de datos para encontrar la plantilla.

Lección 7: Definiciones de datos de enumeración

Las enumeraciones se utilizan cuando se crea una función o programa que tiene información de dominio para un número fijo de dos o más valores distintos. En un ejemplo más del mundo real, porque prefiero esos, piense en la diferencia entre el seguimiento de las calificaciones como valores de letras o como porcentajes. Los valores de las letras son mucho más fáciles de representar en el sentido de que hay menos y están exactamente definidos. Sin embargo, los porcentajes son inexactos y, por lo tanto, no se pueden definir con enumeraciones.

Los puntos principales que se deben tener en cuenta al trabajar con enumeraciones son que las enumeraciones usan la frase "uno de" en su definición de datos, y estos elementos con sangría dentro de la sección "uno de" se conocen como subclases. Además, los ejemplos se vuelven completamente redundantes en las enumeraciones, ya que el ejemplo repetiría literalmente la definición misma.

Lesson 8: Itemization Data Definitions

Las definiciones de datos de desglose se utilizan cuando se necesitan categorías con diferentes estados, con diferentes valores y tipos para una función/programa. Debe haber 2 o más subclases, al menos una de las cuales NO es un valor único y distinto.

Es muy importante tener en cuenta que cuando se trabaja con desgloses de datos mixtos, hay que proteger las subclases adecuadamente para que la función pueda ejecutarse. Esto es necesario porque una subclase que es un Boolean no se puede evaluar de la misma manera que lo haría un Natural, por lo que si no le dice al programa que verifique qué tipo de datos está mirando, puede confundirse y su programa se romperá. Para hacer esto, configura un "guardia". Si está protegiendo un número, por ejemplo, pondría lo siguiente antes de su expresión de evaluación real: (¿número? c).

Esto se usa en Dr. Racket de la misma manera que un compilador en un lenguaje más avanzado entraría naturalmente y verificaría el tipo de datos. Sin embargo, en Dr. Racket, tenemos que hacer esto manualmente.

Lección 9: HtDF con intervalos

Las pruebas cuando se usan definiciones de datos de intervalo son un poco más complicadas que la forma en que se nos ha enseñado anteriormente a escribir cheques esperados en el curso hasta ahora. En el caso de los intervalos, la lección más importante que se difunde en esta sección es asegurarse de probar ambos límites del intervalo, así como un punto medio.

Lección 10: HtDF con enumeración

En lo que respecta a las pruebas con enumeraciones, la clave aquí es probar al menos tantas esperanzas de comprobación como subclases tenga. Si no lo haces, ¡no estás cubriendo todas tus posibilidades!

También se ha señalado en esta lección que no es necesario definir datos por separado para funciones separadas, si residen en el mismo programa. ¡Puede reutilizar sus definiciones de datos!

Lección 11: HtDF con Itemización

En el caso de las pruebas de objetos, desafortunadamente tienes que pensar un poco más para cubrir tus bases. Es fundamental probar todos los puntos de variación en las itemizaciones, así como comprobar los límites de las definiciones adyacentes, para asegurarse de que su comportamiento es el esperado. Es mucho mejor que pruebe a fondo e incluya cualquier caso extremo que se le ocurra, en lugar de terminar su programa, enviarlo a los usuarios y luego tener que arreglar retroactivamente algo que encontraron que estaba "demasiado ocupado" para probar.

Lección 12: Estructura del flujo de información

Identificar la estructura de su información es un paso clave en el diseño de su programa, porque, como dijimos al comienzo de las notas de esta semana, las elecciones que haga en la forma en que elabora sus datos afectarán en última instancia las opciones que tiene al elaborar el código de toda su función/programa.

Terminando la semana 3

Así que en los foros de clase, mucha gente dijo que esta semana fue cuando la clase "se volvió real". Francamente, no estoy de acuerdo. Creo que la semana 3 en muchos MOOC es cuando hay una caída bastante pronunciada porque lo que se presenta va desde el conocimiento generalista hasta se vuelve un poco más profundo. Sin embargo, de nuevo, como mencioné, comencé a ver los videos de la semana 4 y puedo decir con confianza que la semana 4 es donde "se volverá real". ¿Programas interactivos? Eso es algo con lo que puedo emocionarme.

¡Estén atentos para la próxima semana y pueden ver si todavía estoy aguantando con la clase! ¡Hay el doble de contenido de video y estoy seguro de que la tarea va a ser intensa!