Это делалось, скорее всего, для геометрических алгоритмов. Во всех геометрических предикатах можно обойтись только умножением и сложением. Сложные функции, вроде log, скорее всего сами дают неплохую погрешность (там вроде аппроксимация Тейлором или что-то похожее). Зачем нужно деление я не знаю.
Не высказали, но был намек на то, что ваша последовательность имеет ту же вероятность исхода => по аналогии, тот, кому вы отвечали, тоже не должен в неё поверить. Если понял не так, прошу прощения.
Заблуждение. Постфактум — да. Заранее — нет. Есть разница. Вероятность у любой последовательности одинаковой длины одинаковая (1/2^|X|), но только перед броском. Количество орлов в последовательности заданной длины тоже является случайной величиной вообще-то с понятно каким распределением, и последовательность из всех нулей/единиц как раз наименее вероятная.
Не очень убедительно. Доводы как в научно-популярной публикации. То, что «среднее» (матожидание) лица с большой вероятностью красивее отдельно взятого — это весьма логично и понятно без опытов, т.к. вклад каждого «недостатка» из выборки будет мал, а самих вариантов недостатков много. С этим я не спорю. Но почему отклонение (дисперсия?) является мерой красоты? Т.е. почему среднее является самым красивым? Я уверен, что можно найти очертание лица, которое далеко от среднего но покажется человеку красивее среднего.
Вы про обработку старшего коэффициента или про решение над комплексным полем?
«блок-схема» не справится с уравнением x^2-1e20*x+1=0
А как его решать? Интервальной арифметикой? Вообще, казалось бы, достаточно только считать в числах удвоенной точности, если бы не последний коэффициент.
В точку. Я знаю огромное количество хороших специалистов, в прошлом олимпиадников, и это точно не следствие отбора на собеседованиях. А вот программистов 200k+, разрабатывающих сложные системы, и не знающих основ алгоритмов не знаю ни одного.
Ну я могу сказать, что в МФТИ первый и третий пункты более чем верны, насчет второго не уверен. Предполагаю, что во многих университетах как минимум первые 2 пункта верны.
Всё верно. Можно выкрутиться, и сказать, что мы вычисляем N-ное число по модулю M (где модуль M фиксирован и не зависит от N). Тогда действительно будет O(log N). Обычно этот способ и применяется для вычисления по модулю. Для предложенной автором реализации сложность будет примерно такая: сложение двух полиномов за O(N), возведение в квадрат за O(N log N); итераций алгоритма O(log N); тогда итоговая сложность будет O(N log N) для матриц и O(N^2) для тупого алгоритма. У обоих O(N) памяти.
Для оценки первого я пользовался этим:
То же на Haskell по модулю 2^32, но с упрощенными формулами
fib 0 = 0
fib 1 = 1
fib nn = if even nn
then let n = div nn 2 in
(2 * fib (n - 1) + fib n) * fib n
else let n = div (nn+1) 2 in
fib n ^ 2 + fib (n-1) ^ 2
К сожалению, в Haskell нет встроенной длинной арифметики. Сложность вычисления сильно зависит от реализации длинной арифметики. Можно и быстрее, чем за O(N).
Тут дело в том, что приватные читы не привлекают внимания и их не фиксят годами (иногда вообще не фиксят). А как только я напишу статью, появятся желающие повторить это => метод привлечёт внимание => ставит под угрозу чит. И да, читы запрещены и к тому же вредят коммюнити.
Плюсую, я писал чит для Dota 2 который не обнаруживается VAC именно с HB. Кстати, сам процесс разработки был гораздо более сложен и интересен, чем то, что предлагает автор. Хуки vtable уже давно обнаруживаются. Хуки с EndScene тоже. Мне ещё пришлось написать внедрение shared-библиотек в рантайме, и всё это было под Linux (это тоже заслуживает отдельной статьи). В общем, я бы с радостью поделился, но не могу, ибо чит приватный и писался не для себя :D
Ну хотя бы подграфы общая и специальная база я знаю полностью :) А дальше всего понемногу. Есть вообще люди, которые знают весь граф? Это же огромный объем информации.
Да дело-то не в этом. Кто хочет, тот найдет. А люди могли бы свои умственные (и все остальные) ресурсы на более важные проблемы пустить. Хотя откуда там умственные ресурсы…
Есть вообще правила по тому, как проводить проверку решений и требования по тестирующей системе? У меня такое ощущение, что каждый регион делает что хочет.
Вы про обработку старшего коэффициента или про решение над комплексным полем?
А как его решать? Интервальной арифметикой? Вообще, казалось бы, достаточно только считать в числах удвоенной точности, если бы не последний коэффициент.
Для оценки первого я пользовался этим:
К сожалению, в Haskell нет встроенной длинной арифметики. Сложность вычисления сильно зависит от реализации длинной арифметики. Можно и быстрее, чем за O(N).