Segundo parcial de Pensamiento Computacional, resuelto paso a paso

Primero conviene escribir el array terminado, porque todo lo demás sale de mirarlo. El ciclo recorre las tres columnas y en cada una escribe las dos filas:

La primera fila es a tal cual. La segunda es b − a posición a posición: 2−3 = −1, 5−1 = 4, 6−4 = 2.

a) np.zeros((2, 3)) crea 2 filas y 3 columnas, así que M.shape es (2, 3). Siempre en ese orden: shape[0] son las filas y shape[1] las columnas. Confundir uno con otro es lo que hace que un ciclo se vaya de rango sin que se entienda por qué.

b) [1. 4.]

Acá está la primera trampa del ejercicio, y es la que más se falla de NumPy. Los dos índices son [fila, columna], y los dos puntos significan "todas". Entonces:

Los dos puntos están del lado que no se fija. Si el que está fijo es el segundo índice, lo que sale es una columna, aunque se imprima acostada. Y los puntos en [1. 4.] no son decoración: np.zeros crea un array de float, así que todo lo que se guarde adentro se guarda como float.

c) [8. 5.]

Segunda trampa, y la regla para no volver a caer: el eje que ponés es el que desaparece. Con axis=1 desaparece la dimensión de las columnas, o sea que cada fila se colapsa a un número:

Fijate que [2. 5. 6.] —el resultado de axis=0— es justo la lista b, y no por casualidad: la columna j vale a[j] y b[j]−a[j], que sumadas dan b[j]. Es un buen control de que el array está bien armado.

Sin axis, M.sum() suma todo y daría un solo número, 13.0.

d) Fila 1, columna 2: 2.0. Se cuenta desde cero en las dos direcciones.

e) La forma va como una tupla. La firma es np.zeros(shape, dtype): el primer argumento es la forma completa y el segundo es el tipo de dato. Escribir np.zeros(2, 3) le pasa un 3 donde esperaba un tipo, y tira TypeError. Por eso el doble paréntesis: el de afuera es el de la función y el de adentro es la tupla (2, 3).

Para una sola dimensión no hace falta: np.zeros(5) anda, porque un número solo ya alcanza para describir la forma.

La salida completa, en orden:

a) ValueError. El tipo del argumento está bien —es un string, que es lo que int() espera— pero el valor no se puede leer como entero. Esa es exactamente la diferencia entre ValueError y TypeError: int("3.5") es ValueError, "a" + 1 es TypeError.

Ojo con este caso, que confunde: float("3.5") anda perfecto. Es int() el que no acepta un punto decimal adentro de la cadena.

b) listo, y acá está la trampa del ejercicio.

Lo intuitivo es pensar que el return int(texto) devuelve 7 y la función termina ahí, sin llegar nunca al finally. No es así: el finally corre siempre, incluso cuando hay un return en el medio. Python evalúa el return, se guarda el 7 de costado, ejecuta el finally, y recién entonces sale de la función. Así que el print("listo") de adentro pasa antes que el print(...) de afuera.

Y eso no es un capricho del lenguaje: es para qué existe el finally. Es el lugar donde se cierra un archivo o una conexión con la garantía de que se va a cerrar pase lo que pase — que salga bien, que falle, o que alguien haya puesto un return en el medio.

c) 5 líneas. Dos por cada llamada más una:

d) El ValueError no queda atrapado. Un except sólo agarra el error que nombra. Con except TypeError, el ValueError pasa de largo, sube, y corta el programa. Pero el finally se ejecuta igual antes de que el error siga subiendo, así que "listo" aparece en pantalla y recién después el mensaje de error. El finally corre incluso cuando la excepción no se atrapó.

e) Porque el except pelado atrapa absolutamente todo, incluidos los errores que no tienen nada que ver. Si adentro del try escribiste mal el nombre de una variable, eso es un NameError; con except: queda atrapado, se ejecuta el bloque de error como si el dato hubiera estado mal, y el programa sigue andando con un resultado incorrecto y sin avisar. Un error que explota se arregla en cinco minutos; uno escondido puede quedar meses.

La regla práctica: un try chico, alrededor de la línea que puede fallar, y un except por cada error que de verdad esperás. La cátedra marca como mala práctica meter medio programa adentro de un try enorme, justamente porque después no se sabe qué parte falló.

a) 5, y es la trampa del ejercicio.

El archivo se ve como cuatro líneas, pero lo que hay guardado en el disco es una sola cadena:

Fijate el \n del final, después del 140. split("\n") corta en cada salto y devuelve lo que queda entre corte y corte; después del último salto no queda nada, y ese "nada" es una cadena vacía que igual ocupa un lugar en la lista:

b) El control para no depender de la intuición: una cadena partida por N separadores da siempre N+1 pedazos. Hay 4 saltos de línea, así que salen 5 pedazos. Si el archivo no terminara en salto, habría 3 saltos y darían 4.

Esto importa de verdad, no es una curiosidad: la cadena vacía no tiene comas, así que ''.split(",") devuelve [''] y pedirle el campo [1] tira IndexError. Es el error que aparece justo en la última vuelta del ciclo, cuando todo lo demás ya funcionó.

Las dos formas de esquivarlo:

Con f.readlines() el problema no aparece —devuelve una línea por fila, sin el pedazo vacío— pero cada línea viene con su \n pegado, y ahí hace falta .strip(). Un problema o el otro: no hay forma de leer un archivo sin pensar en los saltos de línea.

c) split devuelve una lista, y se imprime con corchetes y con las comillas de cada elemento: ['sucursal', 'unidades']. La coma que separaba se usó para cortar y ya no está adentro de ningún pedazo.

d) La cadena "120", no el número.

Se ve igual impreso, y esa es toda la dificultad. La prueba está en operar: campos[1] + campos[1] da "120120", que es lo que hace + entre cadenas. Para que sea un número hay que convertirlo: int(campos[1]).

Todo lo que sale de un archivo es texto, igual que todo lo que sale de input(). No hay excepción.

e) 120 + 85 + 140 = 345.

Y el programa que lo calcula tiene que hacer las tres cosas de este ejercicio a la vez: saltear la fila de títulos, saltear el pedazo vacío del final, y convertir con int() antes de sumar.

Control: el total tiene que ser mayor que el valor más grande de la columna (140) y menor que 3 × 140 = 420. 345 entra ahí ✓

a) Para saltear la fila de títulos. lineas[0] es "ciudad,temp", y si entrara al ciclo, int("temp") tiraría ValueError y el archivo aparecería con un dato inválido de más.

Es una decisión que hay que tomar leyendo el enunciado, no de memoria: hay archivos con fila de títulos y archivos sin ella. Con títulos va lineas[1:]; sin títulos, lineas entero. Empezar en 1 en un archivo que no tiene encabezado se come el primer dato, y no avisa.

b) Va strip(), o sea campos = linea.strip().split(","). (rstrip() también sirve acá, porque el salto está sólo al final; strip() es la costumbre más segura porque limpia de los dos lados.) readlines() devuelve cada línea con su salto al final, así que la primera es 'rosario,24\n' y sin limpiarla el último campo quedaría '24\n'.

Un detalle fino: int('24\n') funciona igual, porque int() tolera espacios y saltos alrededor. Pero '24\n' == '24' da False, así que en cuanto el campo se compare con algo —un nombre de ciudad, una categoría— el programa deja de andar por un carácter que no se ve. Por eso el strip() va siempre, no sólo cuando hace falta.

c) 2 veces, y el programa imprime:

Las dos por ValueError: int("s/d") falla porque hay letras, e int("") falla porque no hay nada. La cadena vacía es tan inválida como el texto, y es el caso que nadie prueba.

d) Se suman sólo las tres que se pudieron convertir:

e) 20.0 — y acá está la trampa fuerte del parcial.

Las dos cuentas se ven igual de prolijas y las dos dan un número redondo. La diferencia es el denominador, y el enunciado lo dice sin subrayarlo: "el promedio de las temperaturas que sí se pudieron leer". Dividir por 5 es contar dos ciudades que nunca aportaron un grado, y da una temperatura que no existe en ningún lado — 12 °C, cuando el dato más bajo del archivo es 17.

Es el mismo error que aparece en cualquier enunciado con datos sucios, y se evita con una sola costumbre: si el ciclo tiene un contador de válidos, el promedio se divide por ese contador y no por el largo de la lista. Por eso la variable existe.

Control: un promedio siempre tiene que caer entre el mínimo y el máximo de los valores que promediaste. Los válidos van de 17 a 24, y 20 está adentro ✓. El 12 queda afuera, y eso solo ya delata la cuenta.

Le falta una cosa a esta función, dicho sea de paso: si el archivo tuviera todas las filas mal cargadas, validos quedaría en 0 y el return tiraría ZeroDivisionError. La versión prolija chequea if validos == 0 antes de dividir.

f) El primer dato malo cortaría el recorrido. Una excepción no vuelve al lugar donde ocurrió: sale hacia afuera hasta encontrar un except. Si el try abraza el for entero, saltar al except significa abandonar el ciclo, y el programa terminaría con total = 24 y validos = 1, o sea habiendo leído sólo Rosario.

Con el try adentro del ciclo, en cambio, cada vuelta es independiente: la que falla se avisa y se sigue con la siguiente. La regla es esa — el try va lo más chico posible, alrededor de la línea que puede fallar — y es exactamente la que la cátedra evalúa cuando pide "procesar el archivo aunque algunos valores estén mal cargados".

Primero la columna que se agrega, que es de donde sale todo lo demás:

a) (4, 3): cuatro filas y tres columnas, en ese orden. El diccionario tenía tres claves, y cada clave es una columna.

b) 56%. La columna tasa se calcula de una sola vez para las cuatro filas: una columna de Pandas se comporta como un array de NumPy, así que la división y la multiplicación se aplican elemento por elemento sin ningún ciclo.

c) 3. Esta es la primera trampa del ejercicio.

df.copy() crea una tabla nueva, con sus propios datos. Agregarle una columna a df2 no toca df: el original sigue con comision, inscriptos y aprobados, y la copia queda con cuatro.

Lo que hay que ver es el contraste con la otra forma de escribirlo:

Sin el .copy(), después de esa línea df también tendría 4 columnas. Por eso las consignas dicen "un nuevo dataframe, copia del original": es una instrucción, no un adorno, y modificar el original cuando pedían una copia se descuenta.

d) ['A', 'B', 'C']. Se lee de adentro hacia afuera, en tres pasos:

D queda afuera con 40%. Y ojo con qué devuelve cada paso: la comparación no devuelve las tasas grandes, devuelve una columna de True y False, una por fila. Es el mismo mecanismo que el indexado booleano de NumPy.

Para combinar dos condiciones se usa & y |, nunca and y or, y cada condición va entre paréntesis:

e) B, con el 80% — la segunda trampa, y la más importante del ejercicio.

La columna que salta a la vista es aprobados, y ahí C gana cómoda: 28 contra 20. Pero C tenía 50 inscriptos y B tenía 25. En proporción:

B es la única que pasa del 56%, y le saca 24 puntos a la que la sigue. Un número absoluto no se puede comparar entre grupos de distinto tamaño; para eso se calcula la tasa, que es exactamente lo que hace la columna nueva. La cuarta opción —"no se puede comparar"— da vuelta el argumento: que tengan distinta cantidad de inscriptos no impide comparar, es la razón por la que hay que porcentuar.

f) Faltan las etiquetas de los ejes. El título dice de qué es el gráfico, pero no qué mide cada eje ni en qué unidad: quien lo mire no sabe si las barras son cantidades de personas o porcentajes. Son dos líneas:

Es el punto que más se descuenta cuando el parcial pide un gráfico, justamente porque es barato.

Las otras tres opciones, y por qué no: la leyenda no hace falta porque hay una sola serie —sirve cuando se dibujan dos o más y hay que distinguirlas—; el título solo no alcanza; y plt.plot() sería peor, no mejor: las comisiones son categorías sin orden, y una línea entre A, B, C y D sugeriría una evolución que no existe. Barras es lo que corresponde.

Y ya que están las barras: ese plt.ylim(0, 100) no es cosmético. En un gráfico de barras lo que se compara es la longitud, así que el eje tiene que arrancar en 0; si lo recortaras entre 40 y 80, la barra de B se vería varias veces más alta que la de D cuando en realidad es el doble. El eje elegido cambia la historia que cuenta el gráfico.

Los seis se miran de a uno, suponiendo los otros corregidos — si no, se tapan entre sí: el modo "w" corta el programa en la segunda línea, y el return de adentro del while hace que el ciclo no dé nunca una segunda vuelta.

Los seis, en el orden en que aparecen. Los cuatro primeros hacen ruido: el programa se corta y el mensaje de error dice dónde. Los dos últimos son peores, porque no rompen nada: devuelven un número, y el número está mal.

a) El modo. open(nombre, "w") abre para escribir. Hace dos cosas malas de una: readlines() sobre un archivo abierto en "w" no funciona, y —esto es lo grave— "w" vacía el archivo en el instante en que se abre, antes de que se escriba nada. O sea que el programa borra las mediciones y recién después falla. Va open(nombre, "r").

Mejor todavía, with open(nombre, "r") as f:, que cierra solo aunque salte un error en el medio. Con open y close sueltos, cualquiera de los otros cinco errores deja el archivo abierto.

b) La forma del array va como una tupla. np.zeros(shape, dtype): el segundo argumento es el tipo de dato, no la cantidad de columnas. np.zeros(len(lineas), 2) le pasa un 2 donde esperaba un tipo y tira TypeError. Se escribe con la forma adentro de un paréntesis más:

c) La condición del while. Con tres líneas, los índices válidos son 0, 1 y 2. Con i <= len(lineas) el ciclo también entra con i = 3 y pide lineas[3], que no existe: IndexError. Va i < len(lineas).

La regla que evita pensarlo cada vez: el último índice de una lista de n elementos es n−1, así que la condición de un recorrido completo es siempre con menor estricto.

d) Falta i = i + 1. Nada adentro del ciclo mueve el índice, así que la condición nunca deja de cumplirse y el programa se queda leyendo la misma línea para siempre. Es el error más típico del while y el único de los seis que no da ningún mensaje: la computadora simplemente se queda. Va al final del cuerpo del ciclo, después de cargar la fila.

(Si el i = i + 1 estuviera adentro de un if, pasaría lo mismo cada vez que la condición del if diera falso. Vale la pena mirar siempre a qué bloque pertenece.)

e) El return está adentro del while. Esta es la trampa del ejercicio, y la que más puntos cuesta en el parcial real: no tira ningún error. La función devuelve, prolijamente, un array con la forma correcta — sólo que después de UNA vuelta:

Las filas que nunca se cargaron siguen con los ceros que puso np.zeros, y esos ceros después entran a los promedios como si fueran mediciones reales. El return tiene que estar afuera del while, alineado con él.

Por eso la cátedra pide marcar la indentación cuando el parcial se escribe a mano: un renglón corrido cuatro espacios cambia qué hace el programa, y no hay ningún error que lo delate.

f) Fila contra columna. Los dos índices de un array son [fila, columna], y los dos puntos significan "todas":

Otra vez un error que devuelve un número creíble: 27 es un promedio perfectamente razonable, sólo que mezcla una temperatura con una humedad en vez de promediar humedades. Un resultado que no explota no es un resultado correcto.

Las dos funciones corregidas:

Con el archivo del enunciado: cargar("med.csv").shape da (3, 2), el promedio de la columna 0 es 13.0 —(12+18+9)/3— y el de la columna 1 es 42.0 —(40+36+50)/3.

Control, y es el que hay que hacer siempre con un archivo: la cantidad de filas del array tiene que coincidir con la cantidad de líneas del archivo, y cada promedio tiene que caer entre el mínimo y el máximo de su columna. Si aparece un cero en un promedio de temperaturas que van de 9 a 18, hay filas que quedaron sin cargar.

Y una cosa sobre cómo se corrige esto en el parcial: no alcanza con entregar el código arreglado. La consigna pide indicar y explicar cada error, y el corrector descuenta si falta la explicación aunque la versión corregida esté perfecta. Conviene numerarlos y escribir un renglón por error, como está acá arriba.