вот откуда это взялось? Допустим, мне нужно поменять трекпад. Для этого мне НУЖНО отклеить батарею, и я не хочу ее выбрасывать — я хочу приклеить ее обратно.
Будет Ethereum (в котором DAO и Coindash не взламывали), Ethereum Classic (в котором не взламывали только DAO) и Ethereum Much Classic Very Wow (в котором у Виталика нет власти).
Ну, это просто означает, что можно рассчитать генетикой новую ажурную фиговину, которая будет не такой ажурной, и будет лучше справляться с требованиями, которые вы перечислили. Выбраковка-то по этим критериям не производилась.
Если считать, что свет в вагонах инициализирован случайным образом, сходу подумалось о том, чтобы искать самую длинную повторяющуюся последовательность в свете вагонов, таким образом можно найти с некоторой долей вероятности повтор за 2*N вагонов, и увеличивать уверенность в результате за большее количество кругов. Но, с другой стороны, это не сработает, если у вагонов паттерн света повторяется. Мы можем менять один бит в паттерне, как только мы его обнаружили, и начинать отсчет от этого вагона, и идти вперед, пока мы не обнаружим паттерн с измененным битом. Но это не сработает, если поезд "умный" и знает о нашей стратегии, и неизведанные вагоны повторяют наш предыдущий паттерн, каким бы он ни был — поэтому вводить случайную компоненту бессмысленно. Плюс у такого решения очень неоптимальные затраты по памяти — нужно хранить весь трек, и еще и считать автокорреляцию для каждой из промежуточных позиций.
Значит, мы можем изменить трек таким образом, чтобы для его хранения требовался минимум памяти. Например, мы можем зажечь текущий вагон, и затем идти в любом направлении, пока текущий вагон не включен, и считать, сколько будет вагонов до первого горящего. Теперь у нас есть оценка длины цикла. Мы выключаем зажженный вагон, который мы встретили, и продолжаем идти вперед ранее подсчитанное количество шагов. Если встреченный вагон выключен, то с какой-то долей вероятности мы нашли цикл, и можно продолжать идти дальше.
Хотя можно сделать еще лучше. Как только мы нашли первый зажженный вагон, кроме того, с которого мы начали, мы его выключаем, и идем назад требуемое количество шагов. Если изначальный вагон, к которому мы вернулись, еще горит, значит мы погасили не тот вагон, и нам нужно начать заново.
У меня некоторые трудности с тем, чтобы определить временную сложность этого алгоритма, но время растет медленнее, чем O(N^2), но быстрее, чем O(N * log(N)). Сложность по памяти такого решения — O(1).
И не будут ли орнитоптеры или глайдеры более тихими, хотя и менее маневренными?
В статье нет ни слова о копировании человеческого мозга.
Будет Ethereum (в котором DAO и Coindash не взламывали), Ethereum Classic (в котором не взламывали только DAO) и Ethereum Much Classic Very Wow (в котором у Виталика нет власти).
это та, которая патч Бармина?
Ну, это просто означает, что можно рассчитать генетикой новую ажурную фиговину, которая будет не такой ажурной, и будет лучше справляться с требованиями, которые вы перечислили. Выбраковка-то по этим критериям не производилась.
Это все из-за кукурузины на присоске.
"Предметы, извлеченные из прямой кишки"
Поправлять не буду, вы правы.
Все уже придумано до нас.
Если считать, что свет в вагонах инициализирован случайным образом, сходу подумалось о том, чтобы искать самую длинную повторяющуюся последовательность в свете вагонов, таким образом можно найти с некоторой долей вероятности повтор за 2*N вагонов, и увеличивать уверенность в результате за большее количество кругов. Но, с другой стороны, это не сработает, если у вагонов паттерн света повторяется. Мы можем менять один бит в паттерне, как только мы его обнаружили, и начинать отсчет от этого вагона, и идти вперед, пока мы не обнаружим паттерн с измененным битом. Но это не сработает, если поезд "умный" и знает о нашей стратегии, и неизведанные вагоны повторяют наш предыдущий паттерн, каким бы он ни был — поэтому вводить случайную компоненту бессмысленно. Плюс у такого решения очень неоптимальные затраты по памяти — нужно хранить весь трек, и еще и считать автокорреляцию для каждой из промежуточных позиций.
Значит, мы можем изменить трек таким образом, чтобы для его хранения требовался минимум памяти. Например, мы можем зажечь текущий вагон, и затем идти в любом направлении, пока текущий вагон не включен, и считать, сколько будет вагонов до первого горящего. Теперь у нас есть оценка длины цикла. Мы выключаем зажженный вагон, который мы встретили, и продолжаем идти вперед ранее подсчитанное количество шагов. Если встреченный вагон выключен, то с какой-то долей вероятности мы нашли цикл, и можно продолжать идти дальше.
Хотя можно сделать еще лучше. Как только мы нашли первый зажженный вагон, кроме того, с которого мы начали, мы его выключаем, и идем назад требуемое количество шагов. Если изначальный вагон, к которому мы вернулись, еще горит, значит мы погасили не тот вагон, и нам нужно начать заново.
У меня некоторые трудности с тем, чтобы определить временную сложность этого алгоритма, но время растет медленнее, чем O(N^2), но быстрее, чем O(N * log(N)). Сложность по памяти такого решения — O(1).
ммм… квадратичная сложность.
Я бы не использовал конструкцию вида
str(type(obj)) == "<type 'PyIDispatch'>", такой код, как мне кажется, выглядит немного лучше:Второй момент — чтобы экспортируемое имя не было испорчено, оберните его в
extern "C" { ... }ха, да это ж дерево Меркле, только динамически растущее и, похоже, интересное.