A urmat problema *F. Pokemon*, ca dovadă că enunţurile lungi/complicate nu implică neaparat soluţii lungi/complicate, o lecţie valoroasă pentru majoritatea concursurilor de informatică. Pentru idei de optimizare, puteţi citi 'aici':operatii-pe-biti despre cum operaţiile pe mulţimi se împacă foarte bine cu operaţiile pe biţi.

Problema *C. Minlcm* avea nevoie de observaţia că e mai productiv să iterăm peste posibilii divizori comun, decât peste un membru al perechii şi de ideea folosirii unui 'ciur':problema/ciur pentru a o implementa oficient. Mai avea nevoie şi de întregi pe 64 de biţi :).

Problema *C. Minlcm* avea nevoie de observaţia că e mai productiv să iterăm peste posibilii divizori comun, decât peste un membru al perechii şi de ideea folosirii unui 'ciur':problema/ciur pentru a o implementa eficient. Mai avea nevoie şi de întregi pe 64 de biţi :).

Problema *D. Unlock* necesita în primul rând puţină imaginaţie pentru a crea un test în care soluţia brută chiar se comportă foarte prost (idei?). Apoi, era nevoie de o soluţie care se amortiza peste mărimile tuturor componentelor colorate şi o implementare grijulie. Nimeni nu a reuşit să rezolve aceasta problemă din prima submisie, deci ar fi cazul să ne şlefuim puţin abilităţile de implementare :).