Вот, например, задача, которую я могу переформулировать для простоты так. Каждое целое число n изоморфно упорядоченному множеству цифр в своей десятичной записи S(n). Найти сумму по модулю 9 всех чисел, изоморфных элементам булеана множества цифр S(n) данного числа n. Например, для числа 123 это (0+1+2+3+12+23+13+123) mod 9. Алгоритм должен работать по крайней мере для n ≤ 1080.
Задача в принципе не сложная. Мне хватило минут 15 на то, чтобы допереть до алгоритма решения. Что меня потрясло, так это то, что трое лучших олимпийцев решили эту задачу за, соответственно, 86, 90 и 96 секунд. В это время вошло чтение задачи — а там несколько абзацев текста с несколькими примерами чисел, придумывание алгоритма и написание собственно кода. Если до того, как я это увидел, у меня еще были некоторые сомнения насчет своих программистских неспособностей, теперь они развеялись окончательно.
Однажды я прочел книгу по пользованию «Фотошопом», где говорилось, что тот, кто не учится работать с этим редактором клавишами, а тыцает в команды мышкой, не имеет никаких шансов на выживание в скоротечном бизнесе редактирования изображений. Сэкономленные доли секунды в пересчете на каждое действие проводят границу между успехом и неудачей.
В связи с этим у меня вопрос к работающим инженерам-программистам. Скажите, а вы действительно решаете такие задачи за секунды? Насколько вообще напряженна жизнь в вашей сфере? То есть, например, если потратил 5 минут на эту задачу — даже и не думай о том, что напрограммируешь на кусок хлеба, или же все не так запущено? Расскажите о своих впечатлениях от работы.
Comments
как говорил мой дедушка, спешка уместна при ловле блох.
да и вообще какие-то алгоритмы программировать приходится довольно редко, обычно задача так не стоит
за несколько десятков минут разобрать, где в системе размером в миллион строк кода находится нужный кусок, почему он падает, и исправить его, не сломав ничего вокруг.
Опять же, такие задачи при нормально поставленных процессах скорее исключение - но они встречаются, в отличие от описанной в посте.
а где написанные к этому коду инструкции и схемы?
Зачем мучать программеров и заставлять за несколько десятков минут врубаться в забытые программы?
Хороший руководитель имеет необходимую документацию.
Всего доброго, читайте мат.часть и с Новым Годом!
- их же тренируют и, скорее всего, они уже
хотя бы частично этот алгоритм делали,
- возможно у них были заготовки.
Вот так вот :)
Не огорчайтесь ::))
ну, я не знаю, у меня скорость работы примерно 666 (шутка и не шутка, но в среднем от 600 до 670) слов перевода в час с мышкой. Скорость, вообще говоря, неплохая, если судить по итоговым результатам. "Норма" примерно вдвое ниже. Уж я не знаю, сколько слов в час можно выгадать, не пользуясь мышью, тем более, что надо ещё потратить часть ценного мозга на запоминание комбинаций клавиш. Я клавиатурой только в Дежа Вю пользуюсь и в Мемо (потому что там не предусмотрено почти никакх мышьих вариантов), а вот как продуктивно работать в традосе, регулярно нажимая по две-три клавиши служебных - ума не приложу.
В реальном программирование такого не надо, там действительно адекватней пример выше - в системе из миллиона строк найти место и починить.
А сложность алгоритмов - сильно меньше, чем их подгонка под реальные человеческие требования, и чаще всего эти алгоритмы уже сидят готовые внутри баз данных или стека TCP/IP.
А так - вроде данная задачка решается очень быстро, если сразу вспомнить признак делимости на 9 и сообразить, сколько раз каждая цифра войдет в сумму. Ответ n*trunc(log10(n)+1) mod 9 - верный? Хотя за полторы минуты я бы его наверняка не выдал, даже если бы сразу понял условие.
Но для реальной жизни это и правда не требуется. Т.е. решение алгоритмических задачек встречается - но всегда можно позволить себе посидеть немножко с листком бумаги. И всегда желательно потом еще подумать - а не решается ли она одной-двумя стандартными библиотечными функциями =).
Ну и для меня подобные задачки всегда были легче и приятнее, чем периодически встречающаяся задачка "локализовать баг в миллионе строк кода" - их обычно интереснее решать.
А вот об этом желательно подумать как раз сначала :)
Теперь я работаю программистом. Конкретно мне все эти шоткаты и мега-скорость не так важны.
Возможно если клепать сайты на потоке и этим жить - там надо.
Короче если работа достаточно однообразна - там наверное важна скорость, чтобы конкурировать. Если задачи сложные - там другое важнее.
Мне кажется что топкодер - именно про однообразные задачи. Я его считаю задротством и не люблю.
Например, для этой задачи быстро ответит тот, кто просто "умеет" решать данный класс задач.
Для данной задачи:
mod 9 взято для того, чтобы найти не сумму по модулю всех чисел, а сумму по модулю всех цифр этих чисел (10^n всегда даёт в остатке 1 при делении на 9).
Т.е. фактически из неупорядоченного множества цифр, образующего данное число, составить все неидентичные подмножества и просуммировать все цифры этих подмножеств, поделив после этого на 9. Причём нули и девятки можно сразу выкинуть.
Кстати, я не очень понял. А что, ограничения на числа нет? Допустим, в вашем примере число 3333333 даёт множество S(3333333) = {'3'}, соответственно, оно также изоморфно подмножеству S(123).
Даже если забыть про теорему Ферма или про функцию Эйлера, всё равно записанное в лоб выражение N*2^(n-1) (mod 9) вычисляется мгновенно для чисел, занимающих единицы байтов в разумном представлении.
Гонщик может проехать гораздо быстрее, но только в строго отведённых местах. Таксист же знает в своём городе закоулки, срезы, объезды, умеет договариваться с гайцами, усмирять клиентов, может отремонтировать машину (хотя бы знает куда ехать) и т.п.
Совсем другие навыки и другие знания.