Cómo practicar

Practicar

Darren Yao

Alcanzar un nivel alto en programación competitiva exige dedicación y motivación. Para mucha gente, la práctica es ineficiente porque resuelven problemas demasiado fáciles, demasiado difíciles o, simplemente, del tipo equivocado.

En las divisiones más bajas, la mayoría de los problemas usan algoritmos relativamente elementales; el desafío principal es decidir qué algoritmo usar e implementarlo correctamente. En un contest, conviene invertir la mayor parte del tiempo en pensar el problema y diseñar el algoritmo, más que en escribir código. Por eso hay que practicar la implementación, de modo que durante el contest se pueda implementar el algoritmo de forma rápida y correcta, sin tener que recurrir a depurar.

Los problemas con los que se practica deberían tener la dificultad adecuada. No hace falta completar todos los ejercicios al final de cada módulo: hay que hacer lo que resulte adecuado para cada uno. Un problema del nivel correcto es de uno de estos dos tipos: o bien se lucha un rato con el problema antes de llegar a una solución que funciona, o se está cerca y hace falta consultar la solución para alguna parte pequeña. Si la solución aparece de inmediato, el problema probablemente sea demasiado fácil; si faltan varios pasos, puede ser demasiado difícil.

Adicional

Leer soluciones

Saber cuándo “rendirse” en un problema y empezar a leer su solución (editorial o análisis) es difícil. Nótese que “rendirse” va entre comillas, porque igual se aprende cuando uno se “rinde” y lee la solución. A continuación están las opiniones de varias personas.

Darren Yao

En general, me parece bien leer la solución relativamente pronto, siempre que se hayan hecho varios intentos distintos y se pueda aprender de forma efectiva a partir de la solución.

• En un problema de Bronce, leer la solución después de 15-20 minutos sin progreso significativo, después de haber agotado toda idea que se ocurra.
• En un problema de Plata, leer la solución después de 30-40 minutos sin progreso significativo.
• Cuando uno se traba y consulta la solución, no conviene leerla entera de una vez, y desde luego no hay que mirar el código de la solución de inmediato. Es mejor leer la solución paso a paso hasta destrabarse; en ese punto hay que volver, terminar el problema e implementarlo uno mismo. Leer la solución completa o su código debería verse como último recurso.

Nathan Wang

Mi opinión personal es que está bien rendirse pronto al resolver problemas de CP. A veces paso tan solo 15-20 minutos en un problema antes de leer el editorial o al menos echar un vistazo al código de la solución. Otras veces puedo pasar mucho más.

Los editoriales de CP en general no son los mejores (con la excepción de los de USACO, que son bastante buenos), así que a menudo paso mucho tiempo intentando entender la solución incluso después de “rendirme” y leer el editorial. Creo que alcanza con implementar el código sin tener el editorial abierto.

Mi justificación de por qué creo que está bien rendirse tan pronto es la siguiente:

• Frustrarse y dejar CP por una semana es peor que rendirse
  • Cada vez que siento mucha frustración con un problema, leo el editorial
• Los editoriales de CP suelen ser difíciles de entender, así que igual hay que pasar mucho tiempo leyéndolos y entendiéndolos
• Se aprende mucho leyendo editoriales
• Si se puede resolver un problema sin leer el editorial, eso significa que probablemente también se habría podido resolver en contest, así que en realidad no se aprendió tanto. En cambio, si no se sabía cómo resolver un problema y se lee el editorial y ahora sí se sabe, entonces se aprendió mucho más.
  • En otras palabras, leer editoriales es algo bueno, no algo malo.

En general, yo diría que hay que “rendirse” cuando den ganas de rendirse, ya sea a las cinco horas o a los 15 minutos :)

Benjamin Qi

Si todavía surgen ideas nuevas, hay que seguir pensando. Si no, hay varias opciones para destrabarse por cuenta propia:

• Mirar las etiquetas (tags), si están disponibles.
• Leer (parte de) la solución oficial.
• Leer el código de la solución de otra persona (si está disponible públicamente).
  • Esto a menudo ayuda incluso si ya se resolvió el problema uno mismo, porque los competidores de punta a veces llegan a enfoques más limpios que el oficial.
• Dejarlo un rato y hacer otra cosa durante unas horas o días (si se quiere resolver por completo por cuenta propia). A menudo aparecen ideas nuevas en el entretanto.

En cualquier caso, si se pensó mucho un problema durante un contest y no se llegó a resolver, no veo motivo para no leer el editorial cuando sale (en vez de seguir pensándolo por cuenta propia). Además, salvo que se entienda la solución a la perfección, siempre hay que implementarla después.

También se puede consultar mi Github  y mi entrevista de IOI  para más información.

Siyong Huang

Hay dos formas de crecer al resolver un problema:

1 - Se aprende una idea o un algoritmo nuevo.

Las ideas se aprenden de problemas que no se pueden resolver. Eso significa que hace falta leer un editorial o una solución aceptada de otra persona. Siempre conviene empezar por intentar entender el editorial; es una habilidad importante. Un concepto o una idea suficientemente difíciles exigen releer varias veces y dibujar varios ejemplos. Si eso no alcanza, habrá que leer soluciones o pedir ayuda.

Aunque leer soluciones ajenas es difícil, me parece una habilidad increíblemente útil. Si el código apenas se pasa de tiempo, tal vez conviene mirar una solución aceptada más rápida en busca de optimizaciones. Además, ha habido casos raros en los que la solución del editorial queda superada por otra más rápida y más corta. La forma principal en que detecté esto fue leyendo envíos aceptados.

Al pedir ayuda, conviene señalar la idea concreta que confunde. Las preguntas generales terminan respondidas con un resumen del editorial: no es especialmente útil.

Por último, las pistas (hints) están sobrevaloradas en mi opinión. Hay que leer la solución completa. No se gana nada leyendo parte de una solución y terminándola uno mismo. Mientras se implemente al final, se aprende lo mismo.

2 - Mejoran la velocidad y la consistencia de implementación.

La mejor forma de lograrlo es resolver un montón de problemas fáciles o de dificultad moderada. Hay que intentar resolverlos lo más rápido posible, como si se estuviera en un contest. Quizá hacer contests virtuales (virtuals) o cronometrarse al resolver problemas. Sea cual sea la opción, cuantos más problemas se resuelvan, mejor se volverá.

Nathan Chen

Leer el editorial cuando se sienta que ya no hay progreso; eso puede ser de 1 a 5 horas. Sin embargo, lo más importante al leer el editorial es entender el tema e intentar pensar cómo se ven problemas similares. Tener curiosidad en general es una buena forma de practicar el pensamiento algorítmico.

William Lin

Sigo tres criterios (de más importante a menos importante)

1. Divertirse, hacer simplemente lo que apetezca.
2. Dedicar más o menos el mismo tiempo que se tendría en un contest real.
3. Si se está haciendo progreso o no.

Eric Wei

Creo que lo más importante al practicar es intentar sacar algo de cada problema, ya sea un algoritmo o una idea nueva, un truco de implementación que pueda servir más adelante, o simplemente un bug que ojalá no se cometa en el futuro. Dicho esto, los editoriales son más útiles una vez que uno lleva un rato trabado; creo que la exploración que ocurre al estar un poco trabado suele ser instructiva (y buena práctica para contests, cuando es la única opción). Pero en algún punto el problema frustra más de lo que ayuda, y algún momento antes de eso es probablemente el momento adecuado para tomar una pista o leer el editorial.

Michael Cao

Hacer problemas difíciles e intentar aprender algo de ellos. Si se lee el editorial, pensar cómo se llegaría a la solución si hubiera que resolverlo de nuevo. También es importante implementar cada problema cuyo editorial se lea. Lo más importante: no quemarse, o se terminará peor porque la práctica deja de ser eficiente.