Константин Цветков, попробуйте скачать большой файл. Вот я скачиваю, к примеру, файл movie.mp4, а браузер сохраняет его в movie.mp4.crdownload. Пока браузер скачивает, с файлом нельзя работать. Чуть что, браузер его просто удаляет и начинает качать заново.
Vatnik431, в луа написано:
если нажат пробел, нажать бекспейс,
если отжат пробел, отжать бекспейс.
Точно не знаю, как работает ваша система, но по сути она устроена так:
1) один коллега другому сказал, что нужно включить рубильник. Вы это подслушали, и включили свой рубильник тоже.
2) когда коллега говорит выключить, вы снова это подслушиваете и делаете у себя также.
Здесь включать или не включать рубильник у себя, и какой именно - решаете вы. Но запретить другому коллеге переключать свои вы не можете, нужен уровень власти повыше, т.е. нужно идти к начальнику и просить поменять регламент, или самому быть начальником.
То есть вам нужно решить задачу, в которой инфа о нажатии по пробелу должна попадать в луа, но не должна попадать в игру. Как это сделать - не знаю. Кое-кто уже говорил, что никак. Но, может быть, у вас получится. Придётся вмешаться в работу кода на уровне драйверов, скорее всего.
А в чём сложность? Просто объединить два объекта умеете? Перебирать массив умеете? Где проблема-то? :) Похоже на задачу.
Хотя бы попытки решить у вас есть?
SergeySerge11, ну, этой задаче соответствует и обычный массив, получается:
Доступ по ключу, то есть по индексу, - O(1)
Случайное удаление - случайный индекс, - снова O(1), потому что можно без сдвига, на место удалённого переставляем последний элемент массива. Ведь про сортировку речи не было.
Добавление, очевидно, тупо в конец - снова O(1). А если нужно запутывание для какой-то игры - добавляем в случайное место, вместо какого-то элемента, который перемещается в конец. Для "игрока" это равносильно случайному добавлению, т.к. он не будет знать, где какая карта, сколько бы чего ни добавлял.
А если этого мало, то есть нужен не числовой ключ, то, как я уже говорил в ответе, делаем дополнительную хеш-таблицу с ссылками на элементы, которая помогает за O(1) узнавать индекс по вашему ключу.
Однако если, как сказали в другом ответе, вам нужно что-то типа удаления "самого старого элемента", то есть это какой-то выбор и сравнение, то это уже намёк на сортировку и порядок, и нужен совсем другой подход. Просто в вопросе об этом не было ни слова. "Просто какой-то узел удалить" - подразумевает, что у вас уже есть функция, определяющая самый нужный для удаления узел, и её менять/придумывать не требуется.
В общем, если задачу нужно сделать честно, и нет возможности срезать углы, перемешивать карты в любой момент, когда нам вздумается, и нужно вставлять чётко "со сдвигом" и иметь определённый порядок, пусть даже известный только арбитру, то придётся чем-то жертвовать - процессором или памятью, например, или ускорением где-то по цене замедления где-то ещё. Но всё же у вас, скорее всего, специфичная задача, где нужен конкретный результат, а значит, скорее всего, возможна оптимизация, типа игнорирования порядка, удобные преставления, ещё какие-то допущения и упрощения. Это всё зависит от конкретных условий задачи, наличия/отсутствия в ней конкретных ограничений.
В любом случае, хеш-таблица - это, я бы сказал, почти универсальное решение, которым можно приправить любую сложную задачу, даже если сама хеш-таблица не годится в качестве ответа.
1. 50% потерь показывает ICMP. Хотите сказать, что среди UDP пакетов будет при этом не 50% потерь? Про TCP я знаю, что он решает проблему пересылкой, но некое подобие VPN предполагает, что тот же TCP (и любой другой протокол выше сетевого) заворачивается программно, а потом снова пересылается через тот же TCP/UDP. И на этапе этого заворачивания можно придумать всякие штуки типа избыточности. На самом деле это самое простое, что приходит в голову, поэтому это наверняка либо есть, либо есть объяснение, почему так нельзя.
2. Почему только для части протоколов? Я же в вопросе ищу решение для всего трафика в целом, со всеми включёнными в него протоколами. Моя идея была, что в общем случае канал не используется на 100% и можно увеличить количество пересылаемых данных, уменьшив тем самым величину случайных потерь. Конечно, для чего-то типа торрентов это не сработает (да и не потребуется), но почти для всего остального должно сработать. Собственный протокол - слишком круто, но мне кажется, идея избыточности слишком проста, поэтому о создании своего протокола уже думали раньше и не раз.
Почему нельзя решать проблемы TCP находясь выше уровня TCP? Звучит красиво, но это теорема или аксиома?
Повторная пересылка пакета происходит ценой времени ожидания пакета + времени повторной пересылки. И если данных в единицу времени много, то это будет означать "подвисание" TCP соединения.
Я же гипотетически предлагаю весь трафик (включая TCP) поделить на кусочки и завернуть в другой протокол с избыточностью, в котором каждый "кусочек" пересылается дважды, а то и трижды. Пакеты в таком случае идут параллельно, и пересылка как таковая не требуется. Если все дубли не пришли, то пакет просто считается потерянным. Но из-за избыточности снижается процент потерь пакетов в целом для провайдера.
Akina, а можно ли, например, установить некое ПО типа особого VPN с избыточностью в паре с таким же ПО на своём сервере, и таким образом пересылать по несколько пакетов UDP (завёрнутых в свои пакеты, чтобы различать дубли)? Хотя бы в теории?
Dimonchik, а зачем упоминать Питон, если вы не уверены, что в нём тоже есть strip html tags? Тогда уж было бы логично посоветовать воспользоваться PHP, там-то уж точно есть.
К слову, для подобных ситуативных задач даже не нужно ничего устанавливать, сейчас полно онлайн компиляторов (например, этот).
Lynn «Кофеман», без //пояснения я бы разбил на строки, всё равно скорость алгоритма практически такая же, зато читаемость лучше (даже для бывалых).
node.next = new Node();
node = node.next;
или
let new_node = new Node();
node.next = new_node;
node = new_node;
Заметьте, даже после разбора остаётся сомнение, а эквивалентные ли это куски кода. Тот факт, что приходится хоть чуточку напрягаться, признак некрасивости. В идеале код должен читаться, как обычная книга, имхо. Но это дело вкуса, конечно. Для некоторых краткость является более красивой и понятной.
P.S. Ещё говорят, что понты дороже денег. ;) И я не сторонник этой поговорки.
Негоже задавать "дополнительный вопрос" в секции для ответов. Странно, что модератор пропустил это, обычно удаляют.
Также заметил, что вы не помечаете хорошие ответы решениями. Так вы чуть уменьшаете количество потенциальных ответчиков. Неужели ни один из ответов среди всех ваших вопросов не решил соответствующую проблему?
vgray, есть популярные алгоритмы, заточенные на довольно простые случаи, зачастую на общие случаи. Возьмём к примеру, алгоритм сортировки. За какое там время лучший из них справится? За N*log(N), не так ли? Но что если у вас миллиард чисел, каждое из которых от 0 до 255? Тогда уже можно уложиться за O(N) внезапно! А всё потому, что появились дополнительные условия.
У вас довольно специфичные условия, причем их много - количество записей, формат индекса, различные ограничения данных, требования могут быть как к скорости добавления, так и к скорости поиска, а также к объему используемой оперативки, не всегда нужно всё и сразу. И с учётом пересечения всех этих условий вам подойдёт какой-то особый алгоритм, но да, придётся самому "изобретать". А потом ещё и тестировать придётся, чтобы подтюнить его или выбрать из двух разных несовместимых хороших идей.
CityCat4, с прослушкой ребёнка - это жёстко. Возможно, вырастет параноиком и яблофилом)) Хотя определение геопозиции, конечно, всё равно останется в любом случае по факту подключения к сотовой вышке.
movie.mp4
, а браузер сохраняет его вmovie.mp4.crdownload
. Пока браузер скачивает, с файлом нельзя работать. Чуть что, браузер его просто удаляет и начинает качать заново.