Вот у меня уже достаточно давно родился такой вопрос: что в программировании важнее-нестандартный или стандартизированный подход к задаче?
С одной стороны, каждая задача является творческой, и нужно ее уметь сводить к более-менее стандартной задаче. Есть более-менее стандартные методы: нужно посмотреть ограничения, как только на них посмотришь-сразу могут всплыть какие-то стандартные алгоритмы, например, при ограничении 100000-какая-нибудь структура данных, типа дерева отрезков, сортировка ну и так далее. Но для того, чтобы понять, какие можно наложить условия на задачу-нужен какой-то нестандартный подход, умение формулировать эти самые условия и понять, почему они работают.
Есть класс задач, которые можно решить с помощью какого-нибудь стандартного подхода, но, если использовать нестандартный подход-не придется "запихивать", проще и быстрее пишется. Есть задачи, которые без творческого(нестандартного) подхода не решить.
С другой стороны, именно творческий подход иногда мешает. Например, даны ограничения, на которых не до конца понятно, какая асимптотика зайдет-и ты пытаешься придумать решение с меньшей асимптотикой(а решения с меньшей асимптотикой может и не быть). Так же программисты, которые привыкли решать задачи сведением их к более простым задачам, заметно хуже пишут задачи на реализацию(по сравнению с общей массой).
Понятно, что нельзя сказать, что для программиста важнее. Важно, разумеется, и то, и то. Но вот какие задачи решать проще именно вам-те, которые более творческие, или же более стандартные и реализационные задачи?
Многие реализационные, если их написал раз 20-30, начинают казаться простыми и удобными в кодинге:)
"Творческие" задачи - очень условное понятие. Обычно речь идет или о "общем подходе", который просто знают меньше людей, или о какой-то вещи, которую, по своей глупости, просто половина участников не знают, и поэтому пишут какую-то ерунду. Не знают они, допустим, Гауссовского обобщения теоремы Вильсона, да и слабо знакомы с теорией чисел - и тут начинаются проблемы, если задача требует именно этого (может, пример не очень, но просто вспомнил задачу, с которой недавно столкнулся на контесте - большая половина участников зависла из-за весьма поверхностных знаний теории чисел).
На это как-то кстати была задача на opencup, в которой прямо и просили найти произведение всех взаимно простых.
Позволю здесь немного не согласиться по поводу конкретно этой задачи. При знании того, что существует обратный элемент по модулю, и при знании понятия "первообразный корень" решение можно вывести за время контеста. А эти понятия, на мой взгляд, одни из основополагающих в теории чисел, которая уже и на ACM встречается.
P.S. Да, а основная проблема тут в том, что использование Google может дать большие преимущества. А в идеале не должно бы.
У нас несколько команд решили задачу, не зная данного факта
UPD. 2 Ferlon. Решившие у нас команды принципиально не пользуются на контестах гуглом.
Мне рассказывали полулегендарные истории о том, как Дуров и Лопатин на финале на ходу придумали Форда-Фалкерстона, так как они не знали даже такого термина, как задача на максимальный поток.
Правда, я не знаю, сколько в этом правды)
Зависит от конкретного случая. Очень сильно зависит от конкретного случая.
Весной на одном контесте мне было лень думать над задачей - и я писал в ней 4 вложенных тернарника. Естественно, копипастом; так как я мало что вынес в дополнительные функи, а писал почти все в main, то этот быдлокод занимал где-то 400 строк.
Бывают ведь и такие случаи, когда видно, что факторизация работает, и объяснять просто нету времени (можно это после контеста сделать:))
Странно... Мне, наоборот, казалось, что на СФ задачи скорее олимпиадные (хотя тоже простые), а на ТС - на быдлокод. Т.е. тру-олимпиаднику они как бы и очевидны, главное - успеть написать:) Первая - не требует алгоритмов вообще. Вторая - обычно или динамика плоская, или геометрия, или теорвер (решаемый динамикой)...
Ну и третья - уже серьезней, но это третья, ее никто и не решает:) :)
Только не понимаю, зачем заниматься чем-то, и при этом специально так себе усложнять жизнь - мол, не буду учить стандартные алго, а буду их на соревнованиях сразу придумывать:)
Правда я сам собираюсь потихоньку перейти в "клан" олимпиадников - буду летом читать книги и смотреть лекции.
Согласен насчёт интересности и гордости за изобретенные велосипеды - такое очень часто раньше испытывал :)
А для меня придумывание велосипедов и занятия спортивным программированием - это способ интересно и с азартом поумнеть.
И вот так получается что для меня это не ерунда - занимаюсь этим по чуть-чуть уже более года и сам ощущаю что серьезно поумнел и продвинулся в областях прямо с олимпиадным программированием никак не связанных.
Я не совсем правильно выразился... "Учить" - не то слово. Показать дорогу, что ли. Учить как раз не надо - заниматься надо самостоятельно, а не ждать, пока кто-то на блюдечке все принесет.
Но надо, чтобы кто-то "показал дорогу" - указал на сайты с разборами, с алгоритмами, на соревнования по программированию... Я первые полгода занятий даже не знал о существовании ТопКодера.
У каждого свое представление об "олимпиадниках". Все, кто решает что-то на этом сайте, пусть даже второй дивизион - в определенной мере "олимпиадники". Просто одни говорят "он на первенстве факультета был, какие-то там задачи решал - олимпиадник", и при этом понятия не имеют толком, что такое АСМ.
А я знаю команды, которые несколько месяцев подряд тренировались в графике "6 дней в неделю по 8 часов командно + индивидуальные" (или меньше командных - с большим упором на индивидуальные занятия), и понимаю, что тратить на АСМ 5-6 часов в неделю, особенно, если еще кучу разного надо узнать (т.е. в сумме на ТС и СФ рейтинг не 5 с лишним тысяч, а намного меньше) - просто смешно. Тогда это хобби, или способ отдыха, но о серьезных результатах можно только мечтать.
Но если брать ACM, то на мой взгляд в команде нужны оба таких человека: «нестандартный» увидит как можно решить какую-либо задачу, предложит способы, на что «стандартный» ответит написанием нужного из 100500 алгоритмов.
P.s. "more better" is butter which is full of butter :).