eu_tomat

Работает везде, начиная от Linux и заканчивая Вашей кофеваркой

Какой FPS ожидается на Raspberry Pi B+?

Нельзя просто так взять и прекратить изобретение велосипедов.

Есть MineCraft, есть MineTest, и даже Копатель в конце концов. Но и это не предел.

Есть TM, есть OB. Почему существование этих модов должно быть аргументом против создания альтернативы?

хм, а я вообще въехать не могу, для чего это все нужно и какие-то там бутылочки рандомные непонятные? Для чего они? Ну слил в два памфурика 14 единиц в среднем за клик по монитору, ну продал 20 бутылок за кусочек золота Ваське соседу. В чем смысл?  Какая разница в том, золото ли нужно копать и шахтерить или афк-шить возле мобо-качалки или зомбей бить, чтобы набрать опыта сколько-то там или купить его у кого-то. Это же все равно майновская утопия детская.

...

Вон Квертик накопил уже 20К опыта и в ус не дует.  Я даже представить боюсь, какой это лвл, если 30 лвл, это 825 ед. опыта.  И это Квертик будет тыкать в монитор 1,5К раз, чтобы слить весь опыт и получит 3К бутылочек что ли? Для чего это нужно? Это же безумие какое-то А в банке можно мгновенно любое количество снять или положить без потерь четко.

Интерфейс должен быть другим, спору нет. Тыкать в монитор ради одного пузырька – это утомит даже самого автора программы.

Игроки любят «материализацию» – вот, что я имел в виду, оправдывая эту идею. Игроки любят всевозможные пузырьки, которые можно хранить в сундуках и достать в нужный момент. Еще игроки любят, чтобы пузырьков было много, 100500 стаков – в самый раз. А когда эти пузырьки однажды не поместятся в сундук, игроки захотят хранить свое добро на флешках из AE. Понятно, что весь майнкрафт является абстракцией, а сеть AE «дематериализует» даже эту абстракцию, но большинству игроков «материальные» вещи нравятся больше циферок. К примеру, меня полностью устраивают циферки, но поэтому я и в майн почти не играю. А если играю, то мысленно по пути на работу или же изредка запускаю игру для проверки идеи. Но с таким подходом я остаюсь в меньшинстве. Игроки любят предметы. Что касается удобства SQL, то оно относительно:

На мой взгляд, вся прелесть онлайн-игры - её независимость от реального мира. И эту независимость следует соблюдать настолько, насколько возможно. Но, это лишь мое мнение.

Игрокам нравится разнообразие направлений для развития. Поэтому заменять фермы опыта копалками – значит обеднять игру. Моды, подобные Equivalent Exchange, интересны лишь на первый взгляд. К примеру, меня не интересует магия, и на WitchCraft я даже не заглянул. А людям нравится. И с точки зрения автоматизации интересна каждая из этих задач. Игрок, который скачал программу для фермы или шахтера, наслаждается не тем, что он стоит в AFK, а тем, что эта скачанная и непонятная хрень из буковок способна оживить его робота и заставить делать утомительную для игрока работу. Затем игрок пробует модифицировать эту программу или написать свою, наслаждаясь уже тем, что это именно его программа приносит результат. Потом игрок радуется тому, что его программа лучшая и самая эффективная из всех известных ему. По крайней мере, эволюция игроков на computercraft.ru мне видится именно такой.

Идея все-таки неплоха. prostoshu не мечется с вопросами «а чтобы такое написать» и «какие есть идеи». Он придумал и написал. Написал криво, неудобно, да еще и с претензией – вот, что плохо. Не особо нужно на IT – наверное. Но где-то пригодится, если доработать. Лично мне интересно увидеть адекватное развитие этой идеи.

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

Ерунда, конечно, но не полная. Для сервера IT найдется решение получше, но интересна сама идея. Если корректно реализовать вычисление очков опыта и списание уровней, да найти статистически верное содержание очков опыта в пузырьке, этот способ уже будет достоин рассмотрения.

P. S. Неплохо было бы такой терминальчик опыта на IT(это намёк) ))))

А разве банк опыта на IT закрылся?

И если я верно помню, в банке опыта количество опыта учитывалось более адекватно.

Вот вариант схемы: компьютер считывает переодически показания с транспозеров, посылая робота туда, куда надо. Экономим время робота и ускоряем мониторинг.

По-моему, эта схема наиболее универсальна. Роботу достаточно изредка по кругу обходить все реакторы, большую часть времени пребывая в отключке, и таким образом снижая нагрузку на сервер. Транспозеры же, бездействуя, тоже не должны грузить сервер, но они всегда готовы в нужный момент заменить топливо или компоненты в любом из реакторов.

 

В этой схеме отключение робота по TLWY почти не грозит, т. к. тот основную часть времени выключен, включаясь в нужный момент компьютером всегда из одной позиции. Робот включится быстро, т. к. не нуждается в операционной системе.

Робот ведь может крафтить в одно время, а в реакторе шурудить в другое, значит... выкидываем транспозер.

Если реактор один, то достаточно и одного статичного робота.

Если реакторов много, но задержки в их работе не важны, тогда тоже справится один робот, но подвижный.

Если задержки критичны, то желателен отдельный робот на каждый реактор. Но транспозер с сундуком мне кажется более удобным.

 

Впрочем, здесь я слишком увлекся: именно в этих реакторах задержки не играют роли. Но сколько реакторов планирует автор, мы пока не знаем.

Можно для этого использовать телепортатор блоков из gany's end и робота.

Предлагаешь приставить его к каждому реактору?

Вроде-бы очевидно, завод должен быть на транспозерах, если все будет делать робот, то придется весь завод копировать полностью, вплоть до каждого блока (сотни таких прог, которые писались для себя, на коленке, которые никому, кроме автора не интересны). Робота использовать только в качестве верстака.

Полагаю, это утверждение не отрицает применения роботов для перемещения реакторных компонент, топлива и отходов? Иначе, как ты выразился, "придется весь завод копировать полностью" вместе с последовательностью воронок/транспозеров – редкостная тягомотина. Кроме того, изобилие воронок – лагодром, и один «подносящий снаряды» робот на большой АЭС – будет лучшим решением.

 

1)стоит ли пилить робота для заводов мега масштабов,средних , или лучше минимализмом обойтись.

2)можно ли его на компах запилить(и стоит ли)

3)стоит 2 робота делать, или 1-м можно обойтись P.S. как лучше крафтить топливо: по 1-му или кучкой сразу(просто оно состоит из 2-х компонентов и , если 1-го будет не хватать, то придётся выкидывать)

1) Масштабируемая АЭС с произвольным количеством реакторов – это будет бомба.

2) Комп в качестве пульта управления и робот для подсобных задач. И транспозеры, как советовал Doob.

3) С транспозерами должно хватить и одного робота для обслуживания кучи реакторов. Крафтить эффективнее целыми стаками, если для этого достаточно исходных составляющих.

 

хорошо, ну а где тогда схемы реактора хранить, чтобы потом можно было изменять(просто изменять таблицу НИХАЧУ). Правда есть пара вариантов: 1)конечно можно попробовать через сундук с адаптером, но понадобятся различные сундуки(+ схему надо пилить из реальных апгрейтов) 2)куда-нибудь запихнуть апгрейд БД(вопрос только куда и как) предлагаем свои идеи

Не понял вопроса. Хранить схемы можно в файлах.

Вроде-бы очевидно, завод должен быть на транспозерах, если все будет делать робот, то придется весь завод копировать полностью, вплоть до каждого блока (сотни таких прог, которые писались для себя, на коленке, которые никому, кроме автора не интересны). Робота использовать только в качестве верстака.

А может ли транспозер переслать предметы дальше двух блоков?

eu_tomat, так я не понял, в твоих вариантах десятичная точка не обрабатывается? Тогда сравнение не корректно.

@Zer0Galaxy, разве я сравнивал? Ты выдал полное решение задачи, а я лишь пару демонстраций тех моментов, которые меня самого зацепили.

Как использовать метод eu_tomat?

И кстати, кому давать награду?

Мой метод называется "Сделай сам". Я продемонстрировал, как произвести вычисления, используя небольшой объем памяти, и как ускорить запись вычислений в файл. Склеить всё это воедино не составит большого труда. Ну, и добавить обработку точки и чтение из файла, как сделал Zer0Galaxy. Все составляющие у тебя есть.

 

Что делать с наградой, ума не приложу. Меня игровые ресурсы не интересуют. Удивлюсь, если заинтересуется Zer0Galaxy.

Всё-таки не удержался и сделал буферизацию.

local dstName = "result"
local dstL = 10^7
local bufL = 2^12

local dst = io.open(dstName,"w")
local dstBuf

dstBuf = string.rep("0",bufL)
for i=1,math.floor(dstL/bufL) do dst:write(dstBuf) end
dst:write( string.rep("0",dstL%bufL) )

dstBuf = {}
for dstI=dstL,1,-1 do
  local dig = dstI%10
  dstBuf[#dstBuf+1] = dig
  if dstI%bufL==1 then
    dst:seek("set",dstI-1)
    dst:write(table.concat(dstBuf):reverse())
    dstBuf = {}
  end
end

dst:close()

Результаты тестирования разных способов записи в файл на 10M знаков:

29.10 сек - способ Zer0Galaxy() с инверсией промежуточного файла

23.15 сек - уменьшено количество вызовов seek в два раза.

38.13 сек - обратная запись без промежуточного файла

20.19 сек - обратная запись со строковым буфером 32..64 байта

10.15 сек - обратная запись с табличным буфером 4KB

 

Выводы:

1) Уменьшение количества файловых операций даёт хороший результат;

2) Конкатенация строк – неэффективная операция, строковой буфер более 32-64 приводит к потере эффективности. Т.к. Lua не имеет средств для изменения отдельных символов строки, то более эффективными по скорости оказались таблицы;

3) Подтвердились опасения, что запись файла в обратном направлении без буфера может оказаться неэффективной. И это при том, что количество файловых операций уменьшилось.

 

Ускорение записи почти в три раза очень радует.

Если читать файл с конца можно, то дописывать в начало файла не перетирая, а сдвигая написанное, у меня не получилось.

Дописывать файл, сдвигая уже записанное, вряд ли возможно без потери эффективности. Я имел в виду другое решение: заполнить файл нулями или пробелами, а затем выводить результат поверх нулей.

local dstName = "result"
local dstL = 9
-- создание файла и заполнение его пробелами
local dst=io.open(dstName,"w")
dst:write( string.rep(" ",dstL) )
-- заполнение данными с конца файла
dst:seek("end",-1)
for i=dstL,1,-1 do
  dst:write(i)
  if i>1 then dst:seek("cur",-2) end
end

dst:close()

Убеждаемся в том, что файл имеет верный размер и содержимое

$ lua test.lua; cat result; echo""; stat -c%s result
123456789
9

Есть мысль обрабатывать не по одной цифре, а сразу по несколько. По 6, например. Даст ли это прирост к скорости?

На двоичных данных, да в низкоуровневых языках прирост однозначно был бы. Вопрос в том, насколько эффективно Lua может выполнить преобразование в число. Но мне думается, что в нашем случае гораздо большего прироста производительности можно достичь, минимизируя файловые операции, и в этом поможет практически любой буфер, но желательно кратный 512 (или больше, в зависимости от размера кластера файловой системы), и выровненный на начало файла.

@Zer0Galaxy, нужно ли выполнять двойное преобразование файлов?

Читать источник в обратную сторону нам всё равно уже пришлось, а теперь еще добавились прямое чтение и запись.

То же самое и с записью приемника. Два раза идет прямая запись и один раз обратное чтение. Но можно обойтись одной прямой и одной обратной записью. Впрочем, я не знаю, насколько эффективно Lua справляется с буферизацией обратной записи. К тому же отказ от преобразования даст небольшой побочный эффект в виде возможных ведущих нулей или пробелов; не знаю, насколько это критично для целей автора темы.

Буферизацию по любому нужно делать, hhd самая медленная часть пк, большую часть время процессор будет ждать байтики.

Буферизацию делать не буду. По крайней мере, пока никто не сомневается в ее полезности или в возможности реализации.

Я лучше пожертвую памятью, чем производительностью.

Я тоже пожертвую памятью, если она есть. Но я и не утверждаю, что огромные объемы памяти прям-таки необходимы.

В этой задаче они не нужны. Достаточно двух относительно небольших буферов для чтения и записи и еще одного совсем короткого для вычислений.

Или ты опять собираешься всё число считать в память?

Не понятно назначение вот этого куска кода

Для готового кода этот кусок был бы явно лишним. Но код демонстрационный и по возможности универсальный. Поэтому, например, я часть лишнего кода убрал в комментарии, а не удалил совсем. В финальном коде строки источника и приемника должны быть замены файлами, а может, и строковые буферы там будут в каком-то виде. Как топикстартер хранит своё число сейчас и как будет хранить потом, он не прояснил до сих пор. tostring же выдает только один порядок цифр – от старших к младшим.

К стати, совсем не обязательно загружать все число в оперативку целиком. Считывать, умножать и сохранять можно по одной циферке. Если б не ограничение по размеру жесткого диска, думаю и ОС-компьютер справился бы. Долго бы считал, но справился.

Спасибо, что напомнил – я таки не один. Психанул, увидев сообщение NEO и вспомнив предыдущих скептиков.

Может так сделать.

Так и надо. Но если считать этот код готовым, этот блок переменных следует вообще выбросить.

Ну, раз никто мне не верит, что затраты на память очень малы, то курите код:

local mul = "99"
local src = "123456789123456789123456789123456789123456789123456789123456789123456789"
local dst = ""

local char = string.char

local mL = #mul
local sL = #src
-- local dL = #src + #mul
-- dst = string.rep( " ", dL )
local m = tonumber(mul)

local buf,d=0
for i=sL,1,-1 do
  buf = buf + m*(src:byte(i)-48)
  d = buf%10
  buf = (buf-d)/10
  dst = char(48+d)..dst
end
for i=1,mL do
  d = buf%10
  buf = (buf-d)/10
  dst = char(48+d)..dst
end

print( "mul=" .. mul )
print( "src=" .. src )
print( "res=" .. dst )
print()
print( "chk="..tostring( tonumber(mul)*tonumber(src) ))

Осталось лишь заменить строки на файлы. При таком расположении разрядов придется на каждом шаге выставлять нужную позицию в файле, что крайне неэффективно. С этим можно бороться, организовав буферы как для чтения, так и для записи. А можно сменить направление и располагать разряды чисел от младших к старшим, что позволит работать стандартным вводом-выводом даже через пайпы.

 

Еще надо добавить обработку десятичной точки, но на расход памяти заметным образом это не повлияет, и такие числа возможно обсчитать даже на компах OpenComputers, если бы жесткие диски позволили их вместить.

 

 

Я и не иду на рекорд, просто у меня уже есть способ подсчета констант до такой точности, теперь нужен способ их использования в формулах)

 

Я в луа слишком нуб, а другими языками до такой степени пользоваться не умею, умел бы, не просил бы)

Что-то я запутался. Ты не хочешь сам писать умножение, а значит, задача не учебная. Тогда какова ее практическая ценность? Что ты хочешь получить в конечном итоге?

Если я и буду делать калькулятор подобный, который собирался, то не стану рассчитывать на столь огромные числа и столь большую точность. 3*10^8 знаков после запятой - это слишком большое число. Особенно для lua.

А какая нам разница, слишком или не слишком? Задачка интересна тем, что при своей простоте демонстрирует ценность оптимизации кода.

 

DimaZCOM, а что тебе мешает самому написать решение? Ты же каким-то образом смог посчитать число Пи, если я ничего не путаю. И умножение его на двузначное число тоже не будет сложным. Алгоритм умножения столбиком одинаково работает для чисел любой длины.

 

 

Думаю, входные данные (как минимум второе число) программа должна брать из текстового файла. Не с клавиатуры же его вводить. И результат сохранять тоже в файл.

 Возможно. Но условия слабо определены.

Важно знать формат: двоичный, или текстовый. Также важен порядок: старшие или младшие разряды идут первыми. Задействована ли десятичная точка, и как она кодируется. При определенных условиях необязательны и файлы и тем более огромный буфер в памяти. Можно вообще через стандартный ввод-вывод работать, подавая и принимая данные через пайпы. Также интересно, каким образом получено само длинное число. Возможно, имеет смысл изменить алгоритм его генерации для ускорения последующей работы с ним.

 

 

Нужен калькулятор, способный перемножить некое число длинной до 2 цифр на число с 300000000 знаков после запятой.

Слишком неопределенная задача. Каким образом будет вводиться в компьютер число? И куда оно должно выводиться? И в каком формате осуществляется ввод-вывод?

Пустота 7x7 это из области фантастики, ну если генерация карты накручена, но способ передвижения от ноды к ноде надо будет еще подшаманить и с учетом внезапного бедрока.

Фантастика? Не думаю.

Отладочной платой просканирован верхний слой бедрока площадью 401x401, посчитаны все пустые квадраты всех размеров

sq= 1    128600/160801 = 79.97%
sq= 2    65599/160000 = 41.00%
sq= 3    21605/159201 = 13.57%
sq= 4    4712/158404 = 2.97%
sq= 5    723/157609 = 0.46%
sq= 6    111/156816 = 0.07%
sq= 7    26/156025 = 0.02%
sq= 8    7/155236 = 0.00%
sq= 9    1/154449 = 0.00%
sq=10    0/153664 = 0.00%

Вероятность встретить пустой квадрат 7x7 в верхнем слое бедрока равен 0.02%. Это очень мало (и не очеь точно измерено), но вероятно.

Когда пользователь твоей копалки пожалуется на застревание в бедроке, ты вряд ли сможешь воспроизвести проблему, и всё спишешь на глюки майна.

 

Интересно, что квадрат 10x10 в этом сканировании ни разу не встретился, но полагаю, что это тоже лишь вопрос вероятности, а она коварна.

 

Upd: График зависимости вероятности обнаружения пустого квадрата от размера его стороны в логарифмической шкале демонстрирует почти прямую линию, что позволяет прогнозировать вероятность существования пустых квадратов любого размера.

@qwertyMAN, а разве @Zer0Galaxy не указал способ измерений в твоей предыдущей теме?

local a,b,c = 100,200,0
for i=1,ci do c=(a-1)*50+b end
for i=1,ci do c=c+1        end

Второй цикл в среднем выполняется раза в два быстрее первого. Реальная разница будет не так сильно заметна, т.к. её будет размывать время выполнения других операций.

 

+4 байта к оперативной памяти, либо +2 операции

тут нужно решать что важнее, память или скорость.

хотя учитывая что это код на луа, плхоже будет использоваться в ОС, разницы особой быть не должно, скорость не будет заметна учитывая супер скорость майна, а из памяти гцшка сожрет твои 4 байта, если в ду енд запихнешь код с счетчиком и циклом

Тут не просто +2 операции, это две операции в цикле. А +4 байта так и останутся всего лишь 4 байтами, которые так или иначе всё равно будут задействованы. Вопрос лишь в том, насколько важно их освободить по завершении цикла.

Кроме +2 операций следует учесть задействование +2 переменных и +1 константы, что даже в ассемблере будет весьма заметно, не говоря уже о Lua с ее сложной системой доступа к переменным.

1. Возврат у центру столба это лишняя энергия, поэтому при сканировании учитывается смещение от центра и робот не делает лишних движений.

2. Пустота 7x7 это из области фантастики, ну если генерация карты накручена, но способ передвижения от ноды к ноде надо будет еще подшаманить и с учетом внезапного бедрока.

1) Извиняюсь, был невнимателен, возврат не требуется. Лишь точность сканирования падает, но этот вопрос ты уже прояснил.

2) Я не сохранил записи давних экспериментов, а интуиция – не аргумент. Перепроверю, как найду время для майнкрафта.