Если вопрос всерьёз, то видимо в защите интересов тех, кого пресса называет пиратами, а существующее законодательство — преступниками. Но в программе этой партии не очень хорошо разбираюсь.
Мне эти артефакты показались вдвойне удивительны, ведь я-то точно знаю, что PNG сохранял и из них склеивал анимацию. Да вот беда, анимацию склеивал я одним веб-сервисом (wegif.com), шарил на другом (fotki.yandex). Из них искажать мог любой, но похоже всё же это wegif.com.
Да-да, начав набирать название «более редкой вещи».
Попробуем. regedi — слишком короткое начало для regedit?
Введите любые части которые могут встречаться в названии, поиск идет на по полному и точному названию а по любой его части
Надо обновить прошивку. Как же называется программа? Что-то про Flash…
При этом:
Я уже молчу, что вместо того, чтобы мгновенно показать результаты поиска по меню Пуск я вынужден ждать когда же закончится поиск по не интересующим меня файлам.
Так вот зачем Intel встраивает аппаратный генератор случайных чисел! Чтобы skobeltsyn смог точно вычислить площадь многоугольника близкого к дуге окружности. На самом деле подлинность случайности при выборе точек в данном алгоритме не важна.
Пожалуй согласшусь, для такой схемы работы оценка будет верна. Конечно у этой схемы есть свои минусы, и для каких-то очень специфичных задач она не подойдёт, но в целом вполне универсальна.
> Во-первых, данное количество сравнений элементов при коллизиях пренебрежимо мало по сравнению с количеством элементов в хэш-таблице (особенно в большой), отсюда и возникает оценка O(1) (на бесконечности).
Вот тут неточность. Бесконечность малым это количество будет лишь в случае бесконечного значения ключей. Если посмотреть на приведённую Вами таблицу, для метода квадратичных проб и 75% заполненности можно найти два числа — 2.01 и 4.64 (кстати, что такое Successful и Unsuccessful? Лучший и худший случаи?), что подтверждает, что на разрешение коллизии будет тратится время по крайней мере того же порядка.
Да, ну и раз уж Вы в ладах с теорией, давайте откроем определение О(x). Опишите какую-то реализацию хеша, например просто скажите, что его таблица позволяет хранить ссылки для 1000 разных хешей ключей, потом вычислите ту самую константу C, которой должно хватить для любого количества элементов n, тем самым доказав мою неправоту. Потому что я утверждаю, что для O(1) такой константы не существует.
> В эту оценку входит то, что иногда операции могут выполнятся больше одного раза.
Какая разница сколько раз будут выполняться операции поиска элемента, если число элементов много больше количества возможных хэшей?
> в хорошей хэш-таблице оценка количества элементов с совпадающим хэшем пусть и не точно единица, но всё же пренебрежимо мала по сравнению с количеством элемментов
А в идеальной всё ещё лучше, не поверите. Но мы живём в реальном мире и хранение сверхбольшой хэш-таблицы может привести к непозволительному расходу памяти, потому коллизии — далеко не фантастика.
Пост целиком не читал. Мне кажется оценивать сложность доступа к элементу хэша как O(1) неверно, т.к. такая оценка не учитывет коллизий, которые разрешаются за линейное время (от количества элементов с таким же хэшем).
начав набирать название «более редкой вещи».
Попробуем. regedi — слишком короткое начало для regedit?
Введите любые части которые могут встречаться в названии, поиск идет на по полному и точному названию а по любой его части
Надо обновить прошивку. Как же называется программа? Что-то про Flash…
При этом:
Я уже молчу, что вместо того, чтобы мгновенно показать результаты поиска по меню Пуск я вынужден ждать когда же закончится поиск по не интересующим меня файлам.
— DVD-диск для восстановления система
ведь привода нет.
А необычный HDMI — проприетарный что ли? Или есть такой стандарт?
Вообще красиво, конечно.
При перевороте ладья с логотипа LADA превращается в пришельца, а UAZ превращается в ZEN.
> Во-первых, данное количество сравнений элементов при коллизиях пренебрежимо мало по сравнению с количеством элементов в хэш-таблице (особенно в большой), отсюда и возникает оценка O(1) (на бесконечности).
Вот тут неточность. Бесконечность малым это количество будет лишь в случае бесконечного значения ключей. Если посмотреть на приведённую Вами таблицу, для метода квадратичных проб и 75% заполненности можно найти два числа — 2.01 и 4.64 (кстати, что такое Successful и Unsuccessful? Лучший и худший случаи?), что подтверждает, что на разрешение коллизии будет тратится время по крайней мере того же порядка.
Какая разница сколько раз будут выполняться операции поиска элемента, если число элементов много больше количества возможных хэшей?
> в хорошей хэш-таблице оценка количества элементов с совпадающим хэшем пусть и не точно единица, но всё же пренебрежимо мала по сравнению с количеством элемментов
А в идеальной всё ещё лучше, не поверите. Но мы живём в реальном мире и хранение сверхбольшой хэш-таблицы может привести к непозволительному расходу памяти, потому коллизии — далеко не фантастика.