Лидеры

Это обсуждение было отпочковано от темы Майнинг OpenComputer. local function round(num) return num + (2 ^ 52 + 2 ^ 51) - (2 ^ 52 + 2 ^ 51) end Вот мне просто интересно, каждый раз при вызове функции двойка будет четыре раза возводиться в степень? Не будет ли эффективнее сделать так? local huge = 2 ^ 52 + 2 ^ 51 local function round(num) return num + huge - huge end Да и подход к округлению странный. Чем не устраивает math.floor(num+0.5) ? Зачем для получения timeDifference нужно реальное время? Измерять временнЫе интервалы в OpenOS можно не пропиливая жесткий диск. И самый главный вопрос: откуда будут сыпаться биткойны и много ли уже насыпалось?

Это да, но в основном я это придумал для что-бы троллить друзей/управлять роботом сидя на диване с телефоном, а не сидя на стуле и с мышкой.

В общем случае Lua не имеет простого и быстрого механизма сравнения двух произвольных таблиц. В промежуточных случаях есть возможность применить некоторые трюки для ускорения операций. Предлагаю понаблюдать за работой этих команд: component.inventory_controller.store(1,1,component.database.address,1) component.database.computeHash(1) component.me_interface.getAvailableItems()[1].fingerprint.nbt_hash Первая команда запоминает в первом слоте апргейда базы данных информацию о предмете, находящемся в первом слоте сундука, стоящего над контролером инвентаря. Вторая команда вычисляет хеш информации о предмете с учётом NBT-тегов. Третья команда также получает хеш, но уже от МЭ-сети и исключительно NBT-тегов. То есть, два разных предмета, но с одинаковыми тегами будут иметь одинаковые хеши. Этот подход также имеет некоторые сложности: Эти хеши не совпадают, но ассоциативные возможности таблиц Lua позволяют упростить преобразования хэшей. На каждую операцию требуется один тик времени. И если прочитать содержимое МЭ-сети можно за одну операцию, то на обработку каждого слота сундука требуются две операции. Это может представлять проблему для сундуков со свободным доступом для игроков, но информацию о содержимом сундуков с исключительно программным доступом можно кешировать, чтобы избегать повторных вычислений. В конкретно этом случае также возможны хитрости. Необходимость частично игнорировать информацию о предмете делает невозможным прямое использование хешей. Но есть возможность заранее составить таблицы подходящих хешей с учётом вариаций показателей, которые требуется игнорировать. И даже если предварительное формирование и хранение таких таблиц представляет трудность, варианты оптимизации всё равно остаются. Например, можно хранить таблицы хешей только для пчёл, хранящихся в общей МЭ-сети, а для работы с пасеками применять отдельную МЭ-сеть, которая позволит анализировать всех вновь поступивших пчёл и хранить только актуальные хеши.

1) Другого способа сравнения двух таблиц, кроме как поэлементного, не существует. Ты не можешь использовать операторы ">" и "<" для таблиц. Можешь, правда, сравнивать на "равно-не равно", но сравнение всегда вернет falsh, если это разные таблицы, даже если они содержат одинаковые элементы. Другими словами, сравниваются не таблицы, а их адреса. Так что, смирись и брутфорси.