• Записи 1545
  • Теги 109
  • Комментарии 3323

Лог жизни

SberFight — я так и не прошёл в финал

Сегодня как следует отоспался и решил всё же взяться за перепрохождение задач из SberFight. Когда зашёл на сайт, обнаружил, что уже вывалился из ТОП-250, и несколько расстроился. Но решил, что сейчас перепройду несколько задач, и всё же вернусь. Взялся за задачу №3. Оказалось, что бонусные баллы за её решение дают только если решить за 20 минут.
Писать в этот раз решил не на PHP, а на Python — на нём код значительно короче и набирается быстрее. Но увы, и это не помогло. Хотя набросал решение очень быстро, оно не проходило два теста. Стал думать, в чём дело. Довольно скоро нашёл условие, при котором оно действительно не работало (когда во входных данных большая часть элементов имела примерно одинаковые значения и одно-два сильно отличающихся в большую или меньшую сторону). И тут меня переклинило от стресса, что время идёт, а я не знаю, что делать. И только когда прошло минут тридцать, и я решил «всё, теперь уже ничего не поделаешь», вдруг пришло озарение, как надо решать. Причём решение было ну совсем примитивное, просто нужно было решать задачу итерациями, а не пытаться найти формулу, которая позволила бы посчитать сразу, чем я всё это время пытался заниматься.
В общем, прихожу к выводу, что конкурс, где всё ТАК зависит от времени — это не дело для slow liferа: стресса много, толку мало. (Кстати, первый раз я показал более хорошие результаты именно потому что не знал про ограниченность времени, думал, что там по числу попыток запуска кода результат будет считаться.) Потом ещё глянул в рейтинговую таблицу, у первого игрока в рейтинге — целых 4400 очков. То есть 3600 получено именно бонусами за время, и только 800 — за сами решения. Интересно, кстати, там хоть предусмотрели защиту от накрутки? А то имея две SIM-карты, можно делать так: сохранять решения, сделанные под одним аккаунтом, потом регистрироваться ещё раз с другой SIMки, и выкладывать их, переименовав пару переменных, и только за счёт этого быть в ТОПе.

11 комментариев:

Показать еще 1 комментарий
4X_Pro
0

Так сходу приходит в голову ситуация, когда в массиве все нули (хотя этот код вроде должен её корректно обработать) и когда в массиве есть элемент, значение которого превосходит размер массива (например, [1,1,5,1]). В этом случае из условия непонятно, считается ли такая ситуация проходимой или нет. Кроме того, нужно выяснить, что возвращать в случае пустого массива — false или true. По-моему, логичнее второе.

4X_Pro
0

А, нет, на ситуации с массивом из одного нуля этот код вернёт true, хоть это и неправильно.

Нет
Гость
0

Перепробывал все возможные варианты

/** * Implement function getResult */ function getResult(fences) { var len = fences.length; var res = 0; fences.forEach((el) => { if ( el > 0 ) { res += el; } }) if ( res > 0 && res > len-1 && len > 0 ) { return true; } return false; }



Все равно 2 тесткейса которые должны вернуть false фейлятся. Я в сметении. Тут уже дело принципа
Нет
Гость
0

Ты упускаешь главное условие - заборчики можно переставлять. Тебе надо сделать функцию проверки проходимости уровня (от первого элемента до последнего, и проверять что не вывалился за пределы массива при прохождении), и прогнать через эту функцию все возможные перестановки массива.

4X_Pro
0

Я сначала тоже хотел перестановками решать. Но если предположить, что в массиве отрицательных значений нет, то получаем, что непроходимость игры возможна в двух случаях: при попадании на элемент с нулевым значением и при «вылете» за границы массива. Так вот, тогда можно вместо перебора применить такую стратегию: за каждым ненулевым элементом M ставим M-1 нулей и перескакиваем их. Соответственно, если в массиве количество нулей меньше, чем сумма всех элементов, то по нулям игра проходима. Но с другой стороны, количество нулевых элементов меньше суммы тогда, когда сумма больше или равна длине массива, что и делает код, предложенный комментатором. Правда, у него нет второй проверки — «вылета» за пределы массива.

Нет
Гость
0

Задачи разные подбирают ведь, так что есть вероятность, что накручивать надо долго. Но очень странно откуда столько бонусов за время. Решал на Java (коэф 1.9, больше только у шарпа). Решил 3-ю за 2 минуты, дали 280, на шарпе дали бы допустим 300. Умножаем 7*300 = 2100 и плюс 100 за 1-ую будет 2200. Вопрос, какого фига в топ 100 у всех больше... 7-ую например решил за 10 мин, дали тоже 280. Даже если за 7-8 уже идет 400 баллов, а за 4-6 максимум 350, то все равно я не понимаю упорно, какого фига у людей под 3000 баллов. Похоже на какой-то обмен/багоюзерство.

4X_Pro
0

Там ещё за разные языки разный вес? Когда я регистрировался (ещё в декабре), вообще ни слова не было про это…
На мой взгляд, лучше было бы считать не время, а количество попыток отправки кода (submitов). Так как если их число мало, то человек либо изначально код хорошо пишет, либо может сам протестировать его локально перед запуском, в том числе и продумав граничные ситуации.

Нет
Гость
0

какие пограничные значение нужно проверять? решаю через полный перебор сумм элементов массива. Если какая-то сумма равна длине массива то true, иначе false. Решение проходит 6 тестов( добавил случай когда в массиве 1 нулевой элемент, но этого не достаточно

Нет
Гость
0

fences = [-1, 0, 0, 0, 6, 0] вот так например

Нет
Гость
0

насколько я помню, там маленькие ограничения, и перебор заходил

Написать комментарий
Прикрепить файлы: (не более 4 файлов, не более 102400 Кб каждый, 102400 Кб всего)


Задать вопрос