OIA-Politecnico

Entrenamiento

En mi experiencia, hay dos pilares sobre los cuales podemos construir un buen entrenamiento.

• Atacar problemas que están justo fuera de nuestro alcance
• Enfocarnos en hacer contests y upsolvear, no en leer teoría

Para lograr esto, es fundamental participar en contests y tener una lista de problemas que no nos salen, pero que están cerca de nuestro nivel.

Para ver por qué, leer este post de Maxi Redigonda: https://mredigonda.github.io/blog/proper-form-in-competitive-programming/

Estos son otros posts recomendados sobre cómo entrenar, escritos por algunos de los mejores competidores del mundo:

• https://codeforces.com/blog/entry/98621 (importante)
• https://codeforces.com/blog/entry/98806 (una perspectiva un poco distinta)
• https://codeforces.com/blog/entry/66909 (en especial sección 1900-2200)

Contests

Al hacer un contest, por lo general no cerramos la prueba (si lo hicimos, deberíamos hacer contests más difíciles!). Si resolvimos hasta el problema N, el N+3 seguro está fuera de nuestro alcance. Entonces, solo nos preocupamos por el N+1 y N+2.

• Competimos
• El día siguiente al contest (o el mismo día) volvemos a intentar el N+1 (no vale quemarselo)
• Agregamos N+1 (si no salió) y N+2 a la lista
• Si cerramos la prueba, empezamos a hacer contests más dificiles

Upsolving

Upsolvear es resolver problemas que no hayan salido durante un contest (los vamos sacando de la lista de pendientes).

• Tomamos 3 problemas de la lista que hace mucho que no intentes (mejor si es aleatoria la elección)
• Los intentamos durante al menos 3 horas, como si fuera un contest
• El objetivo es resolver al menos uno (que es bastante, siendo que son problemas que antes no nos salieron)
• Si sale alguno, lo borramos de la lista (ver siguiente sección)
• Si no, podemos quemarnos uno leyendo el editorial (ver sección “Editoriales”)

No está bueno que la lista de pendientes se extienda eternamente. Para contrarestarlo, podemos poner más énfasis en hacer upsolving y menos en participar en contests.

Aunque no hay un punto claro donde la lista es “demasiado grande”, está bueno establecer un corte a partir del cual dejamos de participar en contests. Por ejemplo, 40 problemas. (Esto se puede ajustar según haga falta)

Después de resolver un problema

Muchas veces cuando resolvemos un problema, no encontramos la solución más simple. Para ir aprendiendo a hacer esto podemos estudiar la solución oficial y las soluciones de los mejores competidores.

• Resolvimos un problema de la lista, ¿y ahora?
• Leemos el editorial, el código oficial y las soluciones de los mejores, buscamos si había una forma más fácil de hacerlo, o trucos para simplificar la implementación
• Si aprendemos algo nuevo, lo intentamos implementar, pero sin volver a leer el editorial ni códigos de otras personas
• Finalmente, lo borramos de la lista

Editoriales

Un editorial debería darnos el último empujón para que podamos resolver un problema por nuestra cuenta. El objetivo no es que quede el problema resuelto, si no aprender a resolverlo sin ayuda. Entonces, cuando leemos editoriales, tratamos de no spoilearnos.

Una forma de evaluar esto es preguntarnos: ¿lo podré resolver sin ayuda dentro de tres meses?

• No leemos el editorial entero de golpe.
• Vamos leyendo la explicación una frase a la vez (o una pista a la vez, si hay) y pensamos el problema un rato (5-10 minutos) despues de cada una.
• Repetimos eso hasta que nos salga el problema.
• Si el editorial menciona algún tema de teoría que no conocemos, este es el momento de ir a aprenderlo (leer un par de tutoriales, meter un par de problemas)
• Una vez resuelto, hacemos lo que dice la sección anterior.

Conclusiones

Con este método, tenemos una lista de problemas con la dificultad perfecta para nosotros. Nunca ponemos problemas demasiado dificiles, los problemas demasiado fáciles se van filtrando automáticamente y no perdemos tiempo aprendiento teoría que es irrelevante a nuestro nivel. (Un error que cometí, y que es muy común entre competidores de nivel intermedio)

Fuera de eso, está completamente bien divertirse con problemas más fáciles de vez en cuando, siempre que no nos confundamos y pensemos que eso nos ayuda a mejorar.