13 de abril - 19 de abril
Perfilado de sección
-
-
Algoritmos de Ordenamiento y Archivos de Texto
- Ordenamiento: selección, inserción, burbuja, merge sort, quick sort
- Archivos de texto: open, read, write, with
- Temas holísticos: compiladores e intérpretes, procesos del SO
-
El ordenamiento es, junto con la búsqueda, uno de los problemas más estudiados en la historia de la computación. Se estima que más del 25% del tiempo de cómputo en aplicaciones comerciales se dedica a ordenar datos. La razón es directa: muchas operaciones posteriores —búsqueda binaria, eliminación de duplicados, generación de informes, fusión de archivos— requieren que los datos estén ordenados como precondición.
Hasta ahora, nuestros programas reciben datos del teclado y muestran resultados en pantalla. Esa información es volátil: desaparece cuando el programa termina. Los archivos permiten que los datos persistan más allá de la ejecución del programa, almacenándose en medios no volátiles (SSD, disco duro).
En la Semana 4 introdujimos la distinción entre compiladores e intérpretes y vimos cómo Python es un caso híbrido. Esta semana profundizamos en las fases de compilación, conectando este conocimiento con nuestra comprensión de cómo el código fuente se transforma hasta llegar a la CPU.
Cuando ejecutamos nuestro programa de ordenamiento, el sistema operativo crea un proceso para gestionarlo. Comprender el ciclo de vida de un proceso nos permite entender por qué un programa «se cuelga», qué sucede cuando leemos un archivo (el proceso se bloquea esperando el disco), y cómo el SO multiplexa la CPU entre múltiples programas.
-
Los problemas de esta semana integran los algoritmos de ordenamiento (selección, inserción, burbuja, merge sort, quick sort) con el manejo de archivos de texto en Python. El eje temático es la implementación correcta de los algoritmos, su comparación experimental mediante medición de tiempos, y la aplicación a problemas realistas de procesamiento de datos persistentes: análisis de texto y datos estructurados almacenados en archivos.
-
Archivo .txt en formato UTF-8 para prueba del Problema 4
-
Esta actividad te propone hacer una pausa para mirar hacia atrás y analizar cómo venís aprendiendo. No se trata de resumir los temas del curso, sino de reflexionar sobre tu propio proceso: qué te costó, qué te funcionó, y qué podrías mejorar. Es un ejercicio de metacognición — pensar sobre cómo pensás y aprendés — y no hay respuestas "correctas" o "incorrectas": una descripción honesta de las dificultades es más valiosa que un relato optimista que no refleje la realidad.
Estructura sugerida
Organizá tu reflexión en tres momentos. No es obligatorio seguir este esquema al pie de la letra, pero sí cubrir las tres dimensiones.
1. Mirada retrospectiva: ¿qué aprendí y qué me costó?
Identificá qué conceptos o habilidades de las Semanas 1 a 6 te resultaron más desafiantes y cuáles más accesibles. Intentá ir más allá de "me costó ordenamiento" — preguntate por qué te costó: ¿falta de base matemática?, ¿dificultad para pasar del diseño al código?, ¿confusión entre
forywhile?, ¿la notación O grande?, ¿el trabajo con archivos? Mencioná también lo que te resultó más claro o más satisfactorio.2. Análisis del método de trabajo: ¿cómo enfrento los problemas?
Describí cómo encarás típicamente los problemas de laboratorio. Algunas preguntas que pueden orientarte (no es necesario responderlas todas):
- ¿Empezás por el análisis de Pólya (casos de prueba, diseño) o directamente por el código?
- ¿Usás traza manual antes o después de ejecutar?
- ¿Consultás el material teórico antes de intentar resolver, o solo cuando te trabás?
- ¿Recurriste a IA generativa? Si es así, ¿para qué la usaste y qué análisis crítico hiciste del resultado?
- ¿Qué estrategia te funcionó mejor y cuál peor?
3. Proyección: ¿qué voy a mejorar?
Formulá al menos un objetivo concreto y verificable de mejora para la segunda mitad del curso. Evitá declaraciones vagas como "estudiar más" — buscá algo que puedas comprobar si lo cumplís o no. Por ejemplo: "Hacer la traza manual completa de cada problema antes de codificar", "Leer la sección teórica correspondiente antes de la clase práctica", "Escribir los docstrings antes de escribir el cuerpo de la función", "Resolver al menos un problema del bloque de extracursado por semana".
Un ejemplo concreto (recomendado)
En algún punto de la reflexión, elegí un problema específico de cualquier semana que te haya costado especialmente, y narrá el recorrido desde la primera lectura del enunciado hasta la solución funcionando: qué intentaste, dónde te trabaste, qué error cometiste, cómo lo resolviste. Esto ancla la reflexión en la experiencia real y evita generalizaciones vacías.
Extensión orientativa: 400 a 800 palabras (aproximadamente una a dos carillas). No hay máximo estricto: si necesitás más espacio, usalo.
Sobre esta actividad: Esta es la primera de dos reflexiones escritas previstas en el curso. En la Semana 12 se repetirá el ejercicio abarcando las semanas 1 a 12, lo que te permitirá comparar cómo evolucionó tu proceso de aprendizaje a lo largo del cursado.
-
El grupo llega a la mitad del curso con una autoconciencia metodológica notablemente desarrollada. Identifica con precisión la brecha entre “entender el problema en general” y “verlo en el código concreto”, reconoce la tentación de programar sin analizar y exhibe un uso mayoritariamente instrumental y crítico de la IA generativa: la emplea para comprender, no para resolver. Las dificultades duras se concentran donde lo anticipa la planificación (algoritmos de búsqueda y ordenamiento, complejidad/notación O grande, while e iteración indeterminada, y archivos) y comparten una raíz común: el pasaje de lo abstracto a su concreción en código, que el andamiaje Pólya y el contrato QUÉ vs CÓMO apuntan precisamente a cerrar.
-