Skip to Content

Cómo depurar

Recursos
FuenteRecursoNotas
KACTLTroubleshooting

cosas para probar en un contest de ICPC

ErrichtoAsking for help FAQ

Este módulo se basa en los recursos de arriba. Se incluyó el contenido más relevante para USACO.

Antes de enviar

  • El código debería ser legible (al menos para quien lo escribió).

Respuesta incorrecta (o error de ejecución)

  • ¿El formato de salida es correcto?

    • ¿Se quitó la salida de depuración antes de enviar?
  • ¿Se cubren todos los casos borde (como N=1N=1) / casos especiales?

  • En problemas con varios casos de prueba independientes (como este ), ¿se limpian todas las estructuras de datos entre casos?

    • Tener en cuenta que la solución podría fallar solo cuando un caso de prueba es seguido por uno más chico.
  • ¿Se entendió bien el problema? Leer de nuevo el enunciado completo.

  • Leer el código de nuevo.

    • ¿Se están confundiendo NN y MM, ii y jj, etc.?
  • ¿Variables sombreadas , no usadas o sin inicializar?

  • ¿Algún comportamiento indefinido? Puede producir salidas distintas en local vs en línea (p. ej. tal vez el sample pasa en local pero no al enviarlo al juez de USACO). Probar a correr el código en varios lugares (p. ej. USACO Guide IDE , Codeforces Custom Test ) y ver si siempre se obtiene el mismo resultado. Ejemplos comunes de comportamiento indefinido:

    • (C++) Variables sin inicializar

    • (C++) No devolver nada desde funciones que no son void

    • (C++) Arreglo fuera de rango

      • Considerar usar ::at como se menciona aquí.
    • (C++ / Java) Desbordamiento de enteros con signo 

      • Los problemas de USACO suelen incluir una nota de esta forma si el formato de salida requiere enteros de 64 bits en lugar de 32, pero es fácil pasarla por alto:

      Note that the large size of integers involved in this problem may require the use of 64-bit integer data types (e.g., a long long in C/C++).”

    • (C++) Desplazar un entero de 32 bits 32\ge 32 bits

    En C++, compilar con opciones de instrumentación (-fsanitize=address,undefined) puede ayudar a detectarlos.

  • Agregar aserciones y reenviar.

  • Números de punto flotante

    • ¿Algún NaN (p. ej. raíz cuadrada de un número negativo)?
    • Probar un tipo con más precisión (p. ej. long double en lugar de double en C++).
    • ¿Se está imprimiendo la salida con la cantidad correcta de decimales?
  • ¿Se está seguro de que el algoritmo funciona?

    • Recorrer el algoritmo en un caso simple / escribir algunos casos de prueba para correrlo.
    • Escribir un generador de casos y comparar las salidas de la solución contra una solución lenta (más simple), o una solución modelo si hay una disponible.

Error de ejecución

  • ¿Algún comportamiento indefinido? (véase arriba)
  • ¿Alguna aserción que pueda fallar?
  • ¿Alguna posible división por 0? (módulo 0, por ejemplo)
  • ¿Alguna posible recursión infinita?
  • ¿Punteros o iteradores invalidados?
  • ¿Se está usando demasiada memoria?

Límite de tiempo excedido

  • ¿Hay algún posible bucle infinito?
  • ¿Cuál es la complejidad del algoritmo?
  • ¿Se quitó la salida de depuración antes de enviar (p. ej. se está imprimiendo mucha información a error estándar)?
  • ¿Copia innecesaria de datos? C++: considerar pasar variables por referencia.
  • C++: probar a sustituir arrays en lugar de vectors.

Último recurso

  • Reescribir la solución desde cero.
    • Guardar una copia de la solución original. Siempre es posible introducir más bugs en la nueva.

Antes de publicar en el foro de USACO Guide 

  • Si se encontró un caso de prueba chico en el que el programa falla y se sabe por qué la salida esperada es correcta, se debería poder descubrir por qué el programa es incorrecto por cuenta propia.
    • Agregar prints al código y comparar sus salidas con lo que se obtiene al simular el programa a mano.
    • Revisar comportamiento indefinido como se describe arriba.
  • Si no se encontró un caso chico en el que la solución falle,
    • Probar a descargar los datos de prueba oficiales y ver si la solución falla en algún caso chico.
    • Si eso no funciona, intentar generar un caso chico en el que la solución falle, como se describe arriba.