Casos

• Escribe casos ya sea manualmente o autogenerados, siguiendo la especificación de la entrada. No olvides agruparlos de ser necesario, y si hay subtareas, de incluir en su nombre el identificador de la subtarea.
• No borres los casos de ejemplo que ya se encuentran en cases. Si no quieres que esos casos den puntos, puedes asignarles 0 puntos en el testplan.
  • Esto es necesario para que los casos de ejemplo sigan siendo validados; los tests solamente consideran los casos en cases para validación.
• En caso de que los .in de tus casos sean autogenerados, incluye el código que los generó en la raíz del problema, con el nombre case-generator.[lang].
• Antes de planear y generar los casos, considera las siguientes limitaciones:
  • Los problemas en su totalidad deben pesar menos de 100 MiB (incluyendo entradas, redacciones, imágenes, etc.)
  • Cada archivo del caso (.in, .out) no puede pesar más de 2 MiB. Este es un límite estricto: si no lo respetas, las pruebas fallarán.
    • Intenta dejar un poco de holgura para que otras soluciones válidas no reciban OLE, en especial cuando haya múltiples salidas posibles.
  • El tiempo de ejecución máximo para todo el problema es 1 minuto.
• Si la solución oficial no se puede utilizar para auto-generar los archivos .out, hay que generarlos manualmente y agregarlos:
  • Los problemas que tienen un validador personalizado pueden tener .out vacíos si el validador no necesita información más allá del .in original y la salida del concursante para generar el veredicto. También se puede poner información en el .out que le puede ayudar al validador. Por ejemplo, la cota superior / inferior conocida de lo que se desea optimizar.
  • Para los problemas interactivos, como el Main.[lang] típicamente hace las veces del validador, la misma información aplica.
  • Si generar los archivos .out toma mucho tiempo o es necesario generarlos a mano por cualquier razón, hay que agregar el código que los generó en la raíz del problema, con el nombre output-generator.[lang].
• Haz un testplan para tus casos.
  • La convención en la OFMI es que el valor de los casos no puede tener puntos decimales, y el problema necesariamente debe sumar 100 puntos.
  • Cuando hay casos agrupados, la convención es que el primer caso en el testplan debe tener el valor entero del grupo, y todos los demás casos 0. Por ejemplo:

    group.1 40
    group.2 0
    group.3 0
    

• Si es un problema con más de una salida válida, agrega en la raiz el validator.[lang] y cambia en settings.json la sección de validator:

  "validator": {
    "name": "custom",
    "limits": {
      "TimeLimit": 1000
    }
  }

• Si es un problema interactivo, puedes consultar la documentación de libinteractive y usar el problema OMI-2019-Mobius como plantilla para empezar. Lo importante es tener la carpeta interactive/ con un archivo [ModuleName].idl, un archivo Main.cpp con el programa juez oficial y un archivo Main.distrib.cpp que es el programa juez que se va a compartir con los concursantes (por si el juez oficial tiene secretos, o pistas de cómo se resuelve el problema). También hay que agregar a settings.json la sección de interactive:

  "interactive": {
    "ModuleName": "[ModuleName]"
  }