• Mito 1: Un olímpico que participa por primera vez no está en “su año” y por tanto no podrá ganarle a los que ya tienen tiempo
  Realidad: Si bien dos años casi siempre es mejor que uno, 3 o 4 años rara vez resultan mucho mejor que 2. La realidad es que el nivel de todo olímpico está acotado(lo cual no significa que puedan alcanzar su máximo ); si se entrena lo suficiente no es raro que durante el primer año se alcance algo así como un 70% del nivel máximo, y en 2 años un 90%.
  Aunque nunca se deja de mejorar, al principio es muy fácil mejorar pero conforme se va avanzando se va volviendo cada vez mas difícil mejorar un poco; a tal grado de que puede llegar a ser mas productivo estudiar mas ramas de las ciencias de la computación en lugar de seguir con problemas de olimpiada.
  Claro que hay algunos olímpicos que tienen muchos años de participación y el “salto”(la acción de entrenar masivamente para acercarse a su máximo nivel) no lo realizan en los primeros años.
• Mito 2: Más años de participación equivalen a oportunidades mucho mayores de sobresalir.
  Realidad: Analicemos las cosas: En el 2005 yo gané medalla de bronce en la IOI y sólo había participado una vez en el proceso de selección de la OMI(lo que le llaman OMI 8.5 era parte de la 9° y la cantidad de entrenamiento para la IOI del 2004 fue tal vez un 10% que el entrenamiento de cada OMI que siguió, así que con objetividad digo que sólo había participado una vez).
  En el 2006 la selección principal fuimos Nephtalí, Jaime, Felix y yo, el único que no estaba en su primer año fui yo.
  En el 2007 la selección fueron Macs, Nephtalí, Teddy y Marcel, hay que hacer notar que Marcel estaba en su primer año y compitió contra otros que llevaban mas tiempo. Aunque Macs se llevó la medalla y no era la primera vez que participaba, hay que hacer notar que Nephtalí se quedó cerca de la medalla mas o menos por lo mismo que el año anterior(la segunda IOI no siempre es mejor que la primera, de hecho he llegado a pensar que no predomina que la segunda sea mejor que la primera).
  En 2008 la selección fueron Lira, Nieves, Beto y Marcel; Lira ganó medalla de plata( ) y Nieves medalla de bronce, ambos participaban por primera y única vez.
  En 2009 en la IOI quedaron con puntajes muy cercanos todos, y la mitad de ellos participaban por primera y única vez(de hecho creo que esa mitad quedó ligeramente arriba que la otra, pero la verdad no recuerdo bien).
  En 2010 quien quedó mas cerca de ganar medalla en la IOI fué Hugo y participó por primera y única vez.
  Por lo mismo del punto anterior, si pueden participar más veces no implica que vayan a mejorar mucho. El efecto psicológico de tener muchas participaciones puede ocasionar que pospongan “el salto” varios años, eso no es del todo malo, puesto que cada quien decide qué hacer con su vida, el problema es que pueden llegar a aburrirse antes de “el salto”.
  Mi punto de vista es que deben de tomarse cada olimpiada como si fuera la última ya que en cierta medida influye la suerte sobre los resultados(digamos, el tipo de problemas que ponen, puede llegar a afectar el estado emocional del participante(aunque si se preparan para eso deberían poder evitarlo pero tal parece que ignoran ese punto por mas que se les repite)) así que si se puede tener un golpe de suerte favorable en una olimpiada pero no en la siguiente, hay que aprovecharlo.
  Tampoco está por demás mencionar que ha habido varios casos de gente que califica a la IOI en su primer año pero en su segundo año no califica(no porque hayan empeorado, sino porque les llega competencia mas fuerte el segundo año o por una buena racha el primer año).
• Mito 3. La pelea por el pase a la IOI está entre los que ganaron oro en el nacional.
  Realidad. Aunque es mas probable que alguien que ganó oro pueda llegar a la selección, no es raro que alguien que ganó plata llegue a la selección. En 2005 yo fui el único medallista en la IOI y en la OMI correspondiente había ganado plata(tuve un 85/300 en Karel), en 2006 el segundo puntaje mas alto en IOI fue Nephtalí y había ganado plata en la OMI correspondiente(el mas alto fui yo y en la OMI correspondiente ya había ganado oro), en 2007 Macs ganó la medalla y había ganado plata en la OMI correspondiente; en 2008 Lira y Nieves habían ganado oro en la OMI correspondiente, pero Lira ganó el oro mas bajo.
  Sólo mencioné los resultados notables en IOI, pero hay mas casos de gente que llega a la IOI después de una plata en nacional, la razón de esto es que muchos de los que ganan plata en el nacional apenas están empezando y durante el tiempo de entrenamiento logran alcanzar un nivel cercano a su máximo.
  También hay otros casos de gente que siempre pasa en último lugar y llega a IOI, NO SUBESTIMEN A LOS ÚLTIMOS LUGERES EN PASAR.
• Mito 4. Los que llegan a nacional son grandes genios y no se puede competir contra ellos.
  Realidad. A pesar de que la cantidad de inscritos sea muy grande, la mayoría llegan sin saber programar, y muchas veces simplemente entran porque sus escuelas los inscriben. Para que se den una idea de qué tanta competencia tienen para llegar al nacional: no hay estado en el cual más de 4 participantes entrenen al menos 3 horas diarias.
• Mito 5. Ganar una medalla en el nacional es una gran proeza.
  Realidad. Se puede ganar bronce sólo sabiendo usar Karel(para los que estén fuera de contexto, es una aplicación para dar una idea de qué es programar a los que están aprendiendo a programar, pero es mucho mas sencillo que manejar cualquier lenguaje) y a veces sin resolver un problema entero(ha habido nacionales en los que se puede ganar medalla sólo con seleccionar “Nuevo” y “Guardar” en Karel).
  También conozco a gente que ha ganado plata entrenando 2 meses y sin saber programar antes de eso.
  Incluso me atrevo a decir que muchos de los medallistas de la olimpiada nacional no podrían trabajar en una empresa donde se requiera programar (y la mayoría de los graduados tampoco, pueden ver aquí para mayor información http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html ).
• Mito 6. La competencia para llegar a la IOI es enorme.
  Realidad. Es agotadora en cuanto a la cantidad de trabajo, a tal grado de que si un participante está seguro de que no se quiere dedicar a programar el resto de su vida es posible que lo mejor sea no someterse al proceso de preselección (y tal vez tampoco participar, está bien que participen personas que no saben programar para aprender y ver de qué se trata, es agradable que mucha gente aprende a programar en la olimpiada y a través de ahí descubre su pasión; pero si ya saben programar y no les llama la atención, puede que la retirada sea mejor(jaja espero que no me linchen por escribir esto)).
  Sin embargo la cantidad de participantes realmente comprometidos por hacer su mejor esfuerzo y dedicarse a la olimpiada con la mentalidad de que es lo mejor que pueden hacer por sus futuras carreras son pocos. De hecho suelen ser como 17 al año. Así que si alguien participa en la Olimpiada y se esfuerza la probabilidad de llegar a la IOI no es 1/4000 sino 1/4.
  Aún así no recomiendo que entrenen sólo por llegar a la IOI, las habilidades que se aprenden en la Olimpiada les pueden servir toda la vida, incluso pueden adquirir habilidades importantes que no podrían adquirirlas en la universidad (a pesar de que yo llevo materias de CIMAT y las materias de licenciatura tienen muy buen nivel, el estilo de la olimpiada de  explorar ideas y de saber implementar no es algo que enseñen).
• Mito 7. En el proceso de selección para la IOI se invierte demasiado trabajo para algo que no es seguro.
  Realidad. Repito parte del punto anterior :las habilidades que se aprenden en la Olimpiada les pueden servir toda la vida, incluso pueden adquirir habilidades importantes que no podrían adquirirlas en la universidad (a pesar de que yo llevo materias de CIMAT y las materias de licenciatura tienen muy buen nivel, el estilo de la olimpiada de  explorar ideas y de saber implementar no es algo que enseñen).
  Otra cosa importante es que se consiguen contactos con mucha gente talentosa metida en la programación.
  Un dato curioso es que en los últimos años en el concurso para universidades ACM-ICPC han predominado como ganadores de la región equipos con exolímpicos (varios de ellos se habían quedado en últimas etapas para llegar a la IOI pero han logrado llegar a mundiales de ACM después).
  Algo relevante es que aquellos que están terminando sus carreras y en su tiempo fueron buenos olímpicos(sin haber llegado necesariamente a la IOI) están teniendo bastante éxito, muchos han sido contratados por Microsoft y he visto también muchos otros que están teniendo éxito de otras formas.

Así que a los nuevos les digo: no teman, la Olimpiada no es tan difícil y áspera como parece. Entren con la mentalidad de ganar y aprender, si descubren su pasión en la programación entonces no suelten la olimpiada porque puede ser una de las mejores oportunidades que tengan en la vida, aún si no llegan a la IOI; aprendan de los que tienen experiencia pero no les teman, hagan el intento por alcanzarlos ¡si se puede!.

int** matriz;
....
matriz=new int*[n];
for(i=0;i<n;i++){
         matriz[i]=new int[n];
}

No sé si todos estén de acuerdo conmigo de que esta manera de declarar matrices es horrible, es tedioso liberar la memoria a parte de que hay que pedir memoria muchas veces(pedir memoria casi seguro no es O(1), y es posible que se desperdicie memoria debido a que a veces por cuestiones de eficiencia el SO te reserva mas memoria de la que pides, multiplica ese pequeño excedente por n+1).

Tan tedioso llego a ser que a veces optaba por no usar matrices y en lugar de eso acceder a índices de arreglos unidimensionales con algo parecido a arreglo[i*n+k]. Pero hace poco se me ocurrió una alternativa, no es una idea brillante pero sirve para ilustrar que a veces pasamos por alto cosas tan sencillas simplemente por eso: porque son sencillas.

matriz=new int*[n];
int *data=new int[n*n];
for(i=0;i<n;i++){
        matriz[i]=&data[i*n];
}

Como podemos observar, ahora sólo se está pidiendo memoria al SO dos veces. Y liberar la memoria ahora se tornó algo mucho mas simple:

delete [] matriz[0];
delete [] matriz;

No lo puse en el libro debido a que el libro tiene la intensión de enseñar a resolver problemas, no pretende ser un manual de cómo resolver exámenes.

Cómo Resolver un Examen de Olimpiada y No Morir en el Intento

Muchas de las cosas que se mencionan en este artículo son consejos que me canso de repetirles a los olímpicos, espero que ahora que los escribí se los tomen mas en serio.

En esta versión corregí varios errores y agregué capítulos, espero que la aprovechen.

Descargar Libro

Publico este video aquí para darle difusión a ese mensaje y al mismo tiempo para unirme a su causa y decir que yo opino lo mismo: todos tienen derecho a quejarse, pero trabajar es mucho mas importante que quejarse, debemos de trabajar todos por hacer de México un lugar mejor.

Los felicito por haber subido este video.

¡Unámonos a la causa!

Así que sucede un fenómeno poco deseable: la mayoría de los participantes no saben en qué se están metiendo y llegan sin preparación(por no saber en qué deberían prepararse) o llegan preparados en algo diferente a lo que se busca.

Por lo que quienes ganan las primeras etapas muchas veces son quienes por medio de conocidos se enteraron de cómo prepararse o al menos tienen una idea mínima de cómo está el asunto.

Pero hace tiempo encontré un post que describe bastante bien la olimpiada de informática

http://groups.google.com.mx/group/olimpiadas_ciencia_mexico/web/olimpiadas-de-informatica

Coincido en prácticamente todo lo que dice el post, sólo hay un punto que se puede discutir:

“Cuando tengas un problema nuevo trata de categorizarlo como problemas de búsquedas, problemas de grafos o problemas de programación dinámica. Una vez que determinas la categoría de problema puedes pensar en algoritmos que puedes aplicar para resolver el problema. Después de definir la categoría comienza por definir la estructura de datos (variables, arreglos, estructuras, etc.) que usaras para resolver el problema. Finalmente diseña los algoritmos que manipularan esas estructuras de datos entre la entrada que recibiste y la salida.  “

Si bien esto es útil al principio eventualmente tienen que deshacerse de la idea de categorizar los problemas, muchos no entran en ninguna categoría, y algunos aparentan primero pertenecer a alguna categoría pero para resolverlos hay que trasformar el problema en otro análogo y el análogo no tiene nada que ver con la categoría que aparenta el primero.

Normalmente un buen libro es aquel que tiene una portada que muestra una propiedad o un patrón interesante, y un mal libro es aquel que muestra cosas alejadas del tema(como por ejemplo una antena parabólica con una integral a un lado).

Claro que esto no es ley, ya que algunos libros solo tienen el título en la portada y entonces es difícil juzgarlos, y hay unos pocos con portadas engañosas.

Recientemente me he estado fijando en qué libros de las áreas que estudio tienen portadas especialmente emotivas, aquellos libros con solo ver sus portadas me dan ganas de leerlos XD, aquí las comparto:



Sí bien muchas veces se puede saber por la portada que un libro es bueno o malo, tampoco se puede saber qué tan bueno o qué tan malo es por la portada, tomemos el ejemplo del Spivak de una variable, probablemente sea el libro mas bonito de cálculo de una variable y la portada de la segunda edición no es la gran cosa:

La edición que yo tengo es la segunda, pero me acabo de dar cuenta que ya salió la tercera edición y este ya tiene una portada mas emotiva:

Hablando de portadas, usé un árbol con un código de Prüfer como portada de  ”Problemas y Algoritmos” . ¿A Alguien se le ocurre algo mejor?

Sólo puse los nombres de los primeros 6.

Respecto a los problemas, subí casi todos los que hubo en estos entrenamientos y algunos de los anteriores , aquí los enumero:

• De Vacaciones
• Palíndromos(otro, no el que estaba antes)
• Wifi
• Dos Filas
• Otro Juego de Pilas
• Cuenta Árboles
• Fibonacci Modular
• Colección
• Agresivos
• Permutaciones Generadoras
• Collar
• Almacén
• Conexiones
• Orientación
• Segmentación
• Reflexión
• Permutando Columnas
• Cazadores
• Volados
• Diámetro de un Árbol
• Electrocutado
• Hábitos Alimenticios
• Hiring
• Conjuntos de Enteros
• Aterrizando
• Picazo y la OMI
• Gato y Ratones
• Redivisible
• Taxis
• Agentes
• Globos
• Momias de Guanajuato

Con esto se acumulan en total 192 problemas

Si alguien no sabe la dirección es esta: http://www.cmirg.com:8081/traingate

La implementación mas simple que tengo de un segment tree es la siguiente:

struct nodo{
	nodo* izq;
	nodo* der;
	int inicio;
	int fin;
	int clave;
	int cambio;
};

nodo Arbol[N];
int Nodos=0;

nodo* nuevo_nodo(int inicio, int fin, int clave=0){
	nodo* r=&Arbol[Nodos++];
	r->izq=NULL;
	r->der=NULL;
	r->clave=clave;
	r->fin=fin;
	r->inicio=inicio;
	r->cambio=0;
	return r;
}

int consulta(nodo *a, int inicio, int fin){
	assert(a->inicio<=inicio && fin<=a->fin);
	if(a->izq==NULL || (a->inicio==inicio && fin==a->fin)){
		return a->clave+a->cambio;
	}
	int piv=(a->inicio+a->fin)/2, r=-INF;
	if(inicio<piv)
		r=max(r, consulta(a->izq, inicio, min(fin, piv)));
	if(fin>piv)
		r=max(r, consulta(a->der, max(piv, inicio), fin));
	return r+a->cambio;
}

void aplica(nodo* a, int inicio, int fin, int clave){
	assert(a->inicio<=inicio && fin<=a->fin);
	if(a->inicio==inicio && a->fin==fin){
		a->cambio+=clave;
		return;
	}
	int piv=(a->inicio+a->fin)/2;
	if(a->izq==NULL){
		a->izq=nuevo_nodo(a->inicio, piv, a->clave);
		a->der=nuevo_nodo(piv, a->fin, a->clave);
	}
	if(inicio<piv)
		aplica(a->izq, inicio, min(fin, piv), clave);
	if(fin>piv)
		aplica(a->der, max(piv, inicio), fin, clave);
	a->clave=max(consulta(a->izq, a->inicio, piv), consulta(a->der, piv, a->fin));
}

Algo que tuve que cambiar en el segment trie fueron los intervalos de la forma [ ) los tuve que cambiar por [ ]
El segment Trie que implementé quedó así:

struct nodo{
	bool hijos;
	int cambio;
	int bits;
	int clave;
	nodo *izq;
	nodo *der;
};

nodo Arbol[NODOS];
int Nodos=0;

nodo* nuevo_nodo(int clave, int bits){
	nodo *a=&Arbol[Nodos++];
	a->clave=0;
	a->bits=bits;
	a->izq=NULL;
	a->der=NULL;
	a->cambio=0;
	return a;
}

int consulta(nodo *a, int inicio, int fin){
	int aux=(1<<(a->bits))-1, piv=(1<<(a->bits-1));
	int r=-1000000000;
	if(a->izq==NULL || (inicio==0 && fin==aux) ){
		return a->clave+a->cambio;
	}
	if(inicio<piv)
		r=max(r, consulta(a->izq, inicio, min(fin, piv-1)));
	if(fin>=piv)
		r=max(r, consulta(a->der, max(inicio, piv)^piv, fin^piv));
	return r+a->cambio;
}

void aplica(nodo *a, int inicio, int fin, int clave){
	int aux=(1<<(a->bits))-1, piv=(1<<(a->bits-1));
	if(inicio==0 && fin==aux){
		a->cambio+=clave;
		return;
	}
	if(a->izq==NULL){
		a->izq=nuevo_nodo(a->clave, a->bits-1);
		a->der=nuevo_nodo(a->clave, a->bits-1);
	}
	if(inicio<piv)
		aplica(a->izq, inicio, min(fin, piv-1), clave);
	if(fin>=piv)
		aplica(a->der, (max(inicio, piv))^piv, fin^piv, clave);
	a->clave=max(consulta(a->izq, 0, piv-1), consulta(a->der, 0, piv-1));
}

No hubo gran mejora en la implementación, parece que quedó un poco mas limpia gracias a todo lo que pueden hacer los operadores de bits, pero por el momento tendremos que seguir sufriendo para implementar segment trees =P.

Descargar Libro en la Página de Descargas