Veredictos posibles

La solución enviada para el problema ha superado todos los casos de prueba, por lo que el juez la considera válida.

¡Enhorabuena!

La solución enviada no ha superado correctamente los casos de prueba, pero debido únicamente a diferencias en los saltos de línea, espacios o tabuladores.

El juez no considera el envío como correcto; sin embargo te da una indicación de que la solución está muy cerca de serlo. Deberás revisar que la salida sigue exactamente el formato que se indica en el enunciado, poniendo especial cuidado en los separadores. En particular, ten en cuenta que, salvo que el enunciado diga lo contrario, la última línea también deberá terminar con un '\n'.

La solución enviada no ha superado los casos de prueba. El programa se ha ejecutado completamente, pero no da el resultado esperado.

Revisa concienducamente el enunciado y tu solución. Comprueba que, como mínimo, tu programa funciona con los casos de ejemplo, y pruébalo manualmente con otros casos que se te ocurran. Busca especialmente los casos límite del enunciado, por ejemplo el número más alto que puede tener la entrada, el más bajo, etcétera.

¡Este es el veredicto que menos pistas da! Al fin y al cabo, hay muchas maneras de equivocarse al programar y que el código no haga exactamente lo que uno quiere.

El juez ni siquiera ha sido capaz de compilar el código que has enviado. Tienes algún error de sintáxis en el código que hace imposible ejecutarlo. Si accedes a la información detallada del envío (pulsando sobre su identificador) podrás ver la salida del compilador.

Intenta compilar el programa con los compiladores que utiliza el juez para probar localmente el código antes de enviarlo, y no utilices librerías que no sean estándar. Por ejemplo, si programas en Windows, no incluyas windows.h o no uses conio.h.

En los programas en Java, este veredicto aparece también si el código compila pero luego no puede ejecutarse. En concreto, la clase debe ser pública (da igual el nombre y el paquete, siempre que no contengan tildes). Además, obviamente, el main debe ser público, estático y recibir un array de Strings.

El juez ha sido capaz de compilar tu programa, pero durante la ejecución éste ha terminado de manera abrupta antes de procesar todos los casos de prueba.

Si programas en C o C++, asegúrate de que acabas la función main() con un return 0 (acabar devolviendo cualquier otra cosa se considera una finalización incorrecta). Otros motivos de Runtime error al programar en C/C++ son divisiones por 0, accesos con punteros inválidos, accesos a elementos de un array fuera de rango o desbordamientos de pila en recursiones demasiado profundas.

Si programas en Java, la causa principal de este veredicto es la finalización debido a una excepción no controlada. Los motivos por los que pueden surgir excepciones son muchas, algunas de las cuales ya han sido mencionadas en el caso de C/C++. Otra posible causa habitual es intentar leer de la entrada en el formato incorrecto (por ejemplo intentar leer un número cuando según el enunciado viene una cadena o no hay más entrada).

Si sufres un Runtime error busca posibles escenarios en los que podría suceder alguna de las cosas anteriores, por ejemplo probando tu programa con entradas límite. Pero ten en cuenta que las anteriores son sólo algunas de las posibles causas de este veredicto. ¡Hay muchas más razones por las que un programa podría acabar inesperadamente!

El juez ha sido capaz de compilar tu código y de ejecutarlo. Pero ha tardado más tiempo del permitido en dar una respuesta, por lo que se ha cancelado su ejecución.

Si tu programa ha sido capaz de contestar a varios casos de prueba, no se habrá comprobado si eran o no correctos. Es posible que un Time limit exceeded oculte en realidad un Wrong Answer en el caso de que se hubiera dejado terminar al programa.

Si sufres este veredicto, plantéate la eficiencia de tu código. Seguramente haya alguna forma mejor de resolverlo.

Ten en cuenta que un Time limit exceeded no se soluciona con optimizaciones menores, como usar rotaciones para multiplicar o dividir por dos, o ajustar alguna expresión para hacer una sola operación aritmética en lugar de dos o tres. Tampoco se debe al lenguaje de programación.

Los problemas (y casos de prueba) están planteados con rangos de tiempo lo suficientemente generosos como para que pequeñas ineficiencias en el código no signifiquen que se vaya a sufrir un error por tiempo máximo superado. Por tanto, ante un Time limit exceeded deberás plantearte aproximaciones diferentes al problema, intentando por ejemplo eliminar bucles enteros por operaciones sencillas. Otra posible causa de este veredicto en Java es la creación de gran cantidad de objetos (típicamente cadenas) cuando el problema puede resolverse sin ellos.

Los enunciados de los problemas informan del tiempo máximo que se permite usar a las soluciones. A veces da una pista sobre el tipo de algoritmo que debes utilizar.

Existe una última posibilidad para este veredicto que no tiene relación directa con el algoritmo, sino con la detección del fin de la entrada. Si el enunciado dice, por ejemplo, que la entrada terminará con un 0 y tu programa no detecta esa entrada correctamente, entrará en un bucle leyendo de una entrada inexistente, y no acabará nunca. En ese caso, el programa podría estar bien hecho en general, pero al no ser capaz de detectar cuándo terminar consumirá todo el tiempo disponible y sufrirá este veredicto.

El juez ha compilado correctamente tu código y lo ha ejecutado, pero éste ha superado el límite de memoria máximo que se le permite utilizar, por lo que ha cancelado su ejecución.

Si tu programa ha sido capaz de contestar a varios casos de prueba, no se habrá comprobado si eran o no correctos. Es posible que un Memory limit exceeded oculte en realidad un Wrong Answer en el caso de que se hubiera dejado terminar al programa.

Si tu solución sufre este veredicto, revisa la cantidad de memoria que estás utilizando. Utilizar 4 variables en un problema que se puede resolver sólo con 3 no es una razón suficiente para exceder la máxima cantidad de memoria permitida. Tendrás por tanto que buscar usos de memoria grandes, por lo que lo primero que deberías revisar es el tamaño de los arrays u otras estructuras grandes que estés usando. Analiza si se pueden hacer más pequeños o, incluso, si realmente son necesarios o hay soluciones alternativas que no los usan.

Los enunciados de los problemas informan de la cantidad máxima de memoria que se permite usar a las soluciones. Especialmente en los problemas en los que te veas en la obligación de utilizar arrays grandes consulta el valor para tener alguna garantía de que no sufrirás este veredicto.

Si tu código es recursivo (tienes alguna función que se llama a sí misma), en algunos lenguajes podrías sufrir este veredicto si la recursión es demasiado profunda, o si cada llamada necesita mucho espacio para variables locales. Analiza cuánto hueco necesitan esas variables locales y cuál es el número máximo de llamadas que realizarás y confirma que mantienes las necesidades de memoria dentro del límite. Si crees que hay memoria suficiente y aun así sufres este veredicto, confirma que no tienes recursión infinita en ninguno de los posibles casos de la entrada.

El juez ha compilado correctamente el código que has enviado, pero durante la ejecución ha escrito más salida de la máxima permitida, y se ha cancelado su ejecución.

El límite de la salida permitida en el juez es considerablemente superior a la necesaria en cada una de las baterías de prueba; si sufres este veredicto, por tanto, se debe a que tu programa escribe mucho más de lo que debería.

Esto puede deberse a que por cada caso de prueba estás escribiendo cosas que no se piden, como mensajes al usuario o de pruebas. Otro posible motivo es que no detectes correctamente el final de la entrada y tu programa insista en leer el siguiente caso de prueba y en dar una solución para él, que generará salida errónea indefinidamente, superando el límite. Este último tipo de error también es una fuente de veredictos TLE (Time limit exceeded, tiempo límite superado).

Tu programa ha realizado alguna operación que el juez ha considerado ofensiva o peligrosa para el servidor y ha cancelado su ejecución. Si sufres este veredicto, seguramente sepas por qué...

Si no es así, puedes consultar las preguntas frecuentes para más información.

Algunas veces (en realidad muy pocas veces) este veredicto puede encubrir un RTE (Run-time error, error durante la ejecución). Si haces una solución en C/C++ que sufre algún tipo de desbordamiento de buffer que pone al programa a ejecutar código arbitrario, la casualidad podría hacer que ese código intentara ejecutar alguna operación no permitida que tú no has escrito. Si estás convencido de que tu programa no hace nada que pueda considerarse peligroso para el juez (y has leído la entrada de la FAQ), es posible que ésta sea la causa de tu RF, y tengas en realidad un RTE. En ese caso, comprueba, entre otras cosas, que los arrays tienen el tamaño suficiente para los límites del enunciado.

El juez ha recibido tu código, pero todavía no lo ha evaluado. ¡Ten paciencia y dale un poco de tiempo!

El juez ha sufrido algún problema al probar tu código que no es achacable a ti. Es posible que el juez esté en mantenimiento temporalmente, que haya algún error en los casos de prueba o que, en el peor de los casos, tengamos algún error de programación en el juez.

Intenta repetir el envío más adelante para probar otra vez. Dado que el error no será culpa tuya, normalmente no será necesario que realices ningún cambio a tu código.