Вобщем-то простенькое тестовое задание на позицию Trainee Functional Developer, так сказать, для затравки. Я проходил собеседование 2 года назад, поэтому не думаю, что сделаю что-то страшное выложив задание.
Link для ленивых неангличан.
Заявки на конкурс принимаются до 08.02 до 01:00 по Киеву (Москва до 02:00).
Если поддержите плюсиками - запилю бложик отдельно для тестовых задачек, их у меня есть предостаточно. Думаю, будет интересно.
Свой вариант пока не выкладываю, дабы не сбивать ваш полет фантазии.">
Himeg
Torin
Javin
tonyloner
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
Алгоритм уважаемого 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 мс.
Только вот количество итераций как по мне все таки великовато.
Буду думать дальше)
Можешь там модера дать, ты вроде ищещь?
А вот круче было бы сделать отдельный блог для тестовых заданий! Давай сделаем!
Может создадите отдельную тему для всестороннего обсуждения Вашего предложения по блогу? Думаю, что у многих найдутся дельные предложения. «Что быстро рождается, то быстро и умирает», и примеров подобных начатых блогов в Интернете и брошенных — превеликое множество…
Я не вижу причин оттока обучающихся из-за разбора двух-трёх задачек с тестовых заданий от IT-компаний в месяц.
А)
Б) концепцией монетизации курсов, где выгодно именно большое кол-во обучающихся и максимальная доступность курсов.
Исходя из данных соображений, я бы отнес к элитарности людей, уже устроившихся работать по нашему направлению, ибо они обладают всеми описанными качествами:
1) их действительно мало тут.
2) их по сути ничего тут уже не держит. Обычно люди, получив Профит идут дальше, это как школа — всего лишь этап.
3) обладают тем, чего нет у большинства учащихся тут — работой по профилю.
Мое мнение «масштабное» — личные достижения человека определяют его элитарность и круг общения. Как-то так.
И для всех участвующих — не смотрите чужие решения! это в наших же интересах сначала решить по своему, выложить код, а потом ознакомиться с другими решениями.
JuriMik , ты писал что это тестовое задание, а где ты его выполнял? дома или непосредственно в компании? за компом или на бумаге? :) и если за компом, то следили ли за процессом написания, или ты просто выкатил свой результат?
И да, правильно 906609 ;)
потестил ваш алгоритм, когда поставил candidate = 9999999;
алгоритм выдал 898896… то есть с нечетными числами он работать не умеет?
Итак, суть кода сводится к тому, что мы не множим трехзначные числа в попытках найти максимальный палиндром, а, наоборот, перебираем все палиндромы от 999999 до 100001 и проверяем, делится ли очередной палиндром на любое целое число от 100 до 999. Этим и занимается цикл while (palindrome == 0 && candidate > 99999).
Дополнительно, написан метод nextCandidate, который записывает в статическое поле candidate класса PalindromicNumbers очередной палиндром. Изначальное значение поля 997799, поскольку это ближайший палиндром к произведению 999*999. Метод nextCandidate не руководствуется ничем, кроме арифметики, и суть алгоритма сводится к следующему:
1. If ((candidate — (candidate % 10)) % 100000 == 0) candidate = candidate — 11;
если разность candidate и остатка от деления candidate на 10 делится на 100000 (это будут все шестизначные числа вида A0000F), то вычитаем из candidate 11. Пример: 900009. Вычитаем остаток от деления этого числа на 10 из этого же числа. Получаем 900009 — 9 = 900000, делится на 100000 без остатка, следовательно, 900009 — 11 = 899998.
2. Действует по тому же принципу, только для чисел вида AB00EF. Делим на 100, вычитаем из текущего числа и проверяем, делится ли результат на 10000. Если да, то пример: (990099 — 990099%100)%10000 = 0 => чтобы получить следущего кандидата в палиндромы, из 990099 (и любого такого числа) вычитаем 110. Получаем 899998.
3. И, наконец, ABCDEF. Нетрудно догадаться, что если ни одна из
PS хотя, можно переписать его так, чтобы пользователь вводил количество знаков у множителя. Но это будет уже решение в общем виде, т. е. немного другая задача. Сегодня вечером попробую)
а не считали насколько он сократил количество поиска по сравнению с обычным перебором?
А способ от Himeg: 1104 итерации.
очень нужная вещь, думаю все джаворашовцы поддержат.