Alex Gutter, вы напишите Ваше мнение, почему при Х=9, Y=5, правильный ответ 1,0 а не 0,1. Сам я что то не догоняю, и единственное что приходит на ум, это то что жуки более приоритетны чем края при выборе места, но это уже мои домыслы))))
с 94 года, сейчас уже давно пенсионер и занимаюсь этим как хобби. Причина - стал замечать что подтупливаю иногда (как пример - ваше задание, не увидел сразу косячка).
Alex Gutter, есть проблема, не могу понять почему должно получится 1,0, если делаю вручную (с учетом того что правая часть больше) то должно получатся 0,1.
Захар Шайков, если допускается что данные могут быть больше чем их хэш то условие Невозможность найти два разных сообщения с одинаковыми хеш-значениями. в принципе не может быть выполнено.
polikarpovst, при такой постановке задачи авторитетно уиверждаю что ни среднее арифметическое, ни среднее взвешенное найти невозможно, если не оговариватт отдельно дополнительные ограничения и принимаемые условности. Конкретно в вашем случае могу предлодить считать не среднее а суммарный вектор в 2х мерном просранстве. Но я не зная доя чего это вообще вам надо не могу гарантировать что суммарный вектор вам подойдет
polikarpovst, про 6, 13, 20 я не спрашивал среднее значение между парами, нужно среднее значение между всеми 3я цифрами за раз. Сами цифры подобраны таким образом, что если перевести их в углы то это будет 0, 120 и 240 градусов.
Опишите как по вашей логике посчитать среднее между этими 3я углами? (По моей логике сделать это невозможно, и среднее этих углов равно неопределенности)
polikarpovst, я так понимаю, что вы сами не представляете, как считать среднее значение не для пары цифр а например доя трех или более цифр. Спрошу подругому, для чего это нужно? Опишите, что вы хотите делать с этими цифрами на выходе?
polikarpovst, спрашиваю потому, что в случае как вы выразились циклических чисел вообще не может идти речи о среднем значении. Поэтому для того чтобы понять, что же вы хотите получить на выходе, нужна доп информация)))
Alex Gutter, мне бабушка с детства подсовывала книги типа Математическая смекалка. Б.А. Кордемского и они мне очень нравились, я часами и днями мог сидеть, и разгадывать эти задачки. Когда в школе началась геометрия, я на первом же уроке, достал учителя на столько что был вызван к доске со словами "раз такой умный - докажи теорему". Доказал 3-я способами) Далее по жизни все что касается математики, геометрии, инженерной графики в институте, логики и программирования шло как помаслу, ввергая учителей и преподавателей в шок. Я это говорю не для того, чтобы похвастаться, просто уверен, что проведя в раннем детстве много времени за решением математических, геометрических задачек и задачь на смекалку выработал в голове умения видеть пути решения. Я абсолютно не представляю, сколько сил и времени надо потратить взрослому человеку, чтобы добиться такого же эффекта, но думаю, что в разы если не на порядки большего, чем ребенку. Поэтому пожелаю Вам удачи, и посоветую не распылятся на много разных областей.
EVGENY T., после того как вчера написал свой вариант увидел что автор выложил вариант на java. Был очень удивлен, потому что два разных человека независимо друг от друга и ЯП, в терминах которых привыкли мыслить выбрали абсолютно идентичные подходы к решению задачи. Такое на практике бывает достаточно редко. Поэтому возникла мысль, что задача сама подталкивает к такому решению, и скорее всего именно это решение и желали увидеть авторы задачи. По сути данное решение должно производить неявную сортировку массива, за счет использования его как стэка FIFO. Это вполне укладывается в тип задач, цель которых- развивать алгоритмическое решение. Таким образом, чтобы понять, какого подхода к ее решению от нас ждут, надо только выяснить, эта задача дана автору как алгоритмическая или как математическая.
Есть еще 1 момент. Что в моем что в Вашем варианте, каждый последующий жук увеличивает колличество элементов массива, содержащего свободные участки пространства на единицу. В случае с 4 милиардами жуков js однозначно загнется (начинает тупить на массивах, с количеством элементов больше 1000000), а вот вытянет или нет java не скажу.
в примере что вы дали, также округляют слева в большую сторону : var left = (first.Value >> 1) + (first.Value & 1);
данная операция (побитовый сдвиг вправо) эквивалентна делению на 2 с округлением в меньшую сторону: first.Value >> 1
а эта всегда на выходе даст 1 если число нечетное или 0 если четное (first.Value & 1)
то есть если число было например 7 то первая часть даст 3 а вторая 1, в результате левая сторона будет 3+1 = 4
правая же вычисляется как само число - левая var right = first.Value - left--;
отличие лишь в том, что в вашем примере когда берут число свободных посадочных мест не забирают одно под жука. У вас просто уменьшают лево на 1 left-- при вычислении право.
При таком подходе действительно получается с точностью донаоборот, лево-меньшая часть, право большая. Вопрос тут лишь в том насколько принципиально получить при X=8, Y=1 – ответ 3,4 а не 4,3.
На мой взгляд в этой задаче право-лево это всего лишь условность и роли не играют. Но если всеже принципиально, то просто поменяйте в коде округление.
