Вобщем-то простенькое тестовое задание на позицию Trainee Functional Developer, так сказать, для затравки. Я проходил собеседование 2 года назад, поэтому не думаю, что сделаю что-то страшное выложив задание.
Link для ленивых неангличан.
Заявки на конкурс принимаются до 08.02 до 01:00 по Киеву (Москва до 02:00).
Если поддержите плюсиками - запилю бложик отдельно для тестовых задачек, их у меня есть предостаточно. Думаю, будет интересно.
Свой вариант пока не выкладываю, дабы не сбивать ваш полет фантазии.">
Himeg
Torin
Javin
tonyloner
JuriMik
26 уровень
Алгоритм уважаемого Himegа даёт, похоже, наибольшее быстродействие. Но лично для меня, к сожалению, он так и остался вне понимания.
Осталось загадкой и то, что никто пока не использовал возможности многопоточности. Хотя некоторые участники, предполагаю, разбираются и в ней. Почему же они не стали применять эту технологию? Ведь практически у всех в персональных компьютерах стоят многоядерные микропроцессоры и от параллельных вычислений, полагаю, можно получить прирост в быстродействии.
Intel Core i7-2600 CPU @ 3.4 GHz x 4, RAM 16 GB, Linux
Наибольший палиндром для произведения 3-значных десятичных чисел: 993 * 913 = 906609
Время поиска палиндрома составило: 563039 наносекунд
Примечание
Пусть для палиндрома 178871 найдено одно из трехзначных чисел 707, то второе вычисляется как 178871 / 707 = 253. И после отыскания числа в диапазоне от 999 до 500 уже не имеет смысл поиск другого числа, т. е. 253, в диапазоне от 100 до 499, так оно элементарно вычисляется.
На вот это
и получил 0-4 мс! инициализация переменных столько жрет??!
Уже потом посмотрел, как кто реализовал и дошло.
В моем решении слишком много вычислений проводится в методе findPalindrome(). Мне кажется сам процесс перебора и умножения мало относится к задаче «найти наибольший палиндром». Можно ли вычисления сделать предварительными? я могу загнать данные в TreeMap с ключем равным произведению, которое будет записано в стринге (которую потом просто распарсю). Таким образом палиндром будет проверяться по ключам TreeMap. Я не знаю насколько быстро происходит изъятие из TreeMap, но я бы избавился от вложенного цикла и от операции умножения. Я думаю это окупится процентов на 150%
Но на заполнение карты тратится 713 мс
Вообще не кошерно, даже чувствуется притормаживание перед выводом в консоль :(
ЗЫ блин как же не удобно без спойлеров! так бы код можно было под спойлер засунуть, а из-за их отсутствия растягивается на 100 метров…
с одной стороны был явный намек на интерес к умению рефакторинга, с другой стороны вполне могли ждать реализации алгоритма Манакера, но его надо знать =\
Указанный тобой алгоритм мне кажется сюда не очень подходит ;-)
Я выкатываю первую версию своего кода, однако оставляю за собой право на правки до 08.02.
Но если вдруг окажется, что все норм, то #на_конкурс.
#НА_КОНКУРС_v_2
intel core i5 6200U @ 2.30 Ghz (ноут)
7 мс.
Только вот количество итераций как по мне все таки великовато.
Буду думать дальше)
Можешь там модера дать, ты вроде ищещь?
А вот круче было бы сделать отдельный блог для тестовых заданий! Давай сделаем!