Bugs que me pasaron hace poquito

Se me ocurrió anotar qué pasó cada vez que tenía un bug haciendo un problema (mentira, seguro me olvidé un montón de veces de anotar, pero lo intenté).

Algo que no hice es anotarme en qué problema me pasó cada bug. Si me acuerdo, en Febrero lo hago.

Enero 2018:

Bugs Implementativos:

  • Creer que x & (1 << k) devuelve 1 si el k-ésimo bit está encendido cuando en realidad x & (1 << k) devuelve 2^k si el k-ésimo bit está encendido.
  • Responder y hacer break sin terminar de leer toda la entrada (Este fue muy raro)
  • Me comí un +1 en un límite izquierdo, lo cual hacía que no chequee la última ventana en un two pointer (n-k en vez de n-k+1). Se arreglaba haciendo un dibujito antes de mandar. (me pasó dos veces distintas el mismo bug durante Enero, triste)
  • Tenía un “<” donde iba un “<=”, la ventana de otro two pointer me quedaba mas chica de lo que quería (por uno).
  • maxN iba hasta 2^(n/2) que era lo que necesitaba, pero en el código inicializaba en 0 unos arreglos hasta 2^n (en vez de n/2). Runtime error por acceder fuera de rango.
  • Leyendo n-1 aristas de un árbol indexado en 1, estaba guardando la lista de padres corrida todo un lugar. Increíblemente pasaba los ejemplos.
  • Daba TLE porque *max_element en multiset es lento. Como están ordenados, se arregla poniendo *–miMultiset.end().
  • Tener un “+=” donde iba un “=” (lo triste de este bug es que antes de mandarlo le corrí un caso donde fallaba, pero no chequeé que la solución de efectivamente lo que tenía que dar, solo me fijé que “tenga la pinta que tenía que tener”. Triste)
  • Codear mal algo que cuenta la cantidad de apariciones de un número y no testearlo (y asumir que esa parte estaba bien). Imprimir siempre la salida de forma intermedia y chequearla puede ayudar a que no pasen estos bugs otra vez.
  • Generar un arreglo de sumas parciales (tablita aditiva) que iba módulo un número y olvidarse de tomar módulo al primer elemento del arreglo.
  • No dar suficiente changüí a una variable. Accedía a A[i+m] y la cota de maxN estaba pensada para acceder A[i].

Bugs Mentales:

  • Leer y no recordar en el enunciado que decía “positive integer”
  • Olvidarse de escribir un cartel al leer/pensar el problema que diga “OJO NO DIVIDIR POR CERO” (después faltó agregar un if en el código que era evitable)
  • Imprimía un numerito de menos en algunos casos (pero estaba bien especificado en el enunciado cómo imprimir).

memePalpatine

2 Me gusta

Excelente post!!!

Comento que:

No es que sea lento “en multiset”, sino que es “lento” siempre. Concretamente, “find” , “max_element” y similares funciones de la biblioteca algorithm, hacen búsqueda lineal, así que la complejidad es lineal. La ventaja y la razón por la que hacen búsqueda lineal, es que justamente funciona con cualquier cosa eso: Le podés dar un set, un multiset, un deque, un vector, un arreglo de C plano, tu propio tipo de datos que implemente sus propios iteradores, y la misma función sirve para todos. Por eso algunas estructuras tienen su propio .find() mucho más rápido (como es el caso de set/map).

2 Me gusta