eu_tomat

Ну, раз никто мне не верит, что затраты на память очень малы, то курите код: 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, если бы жесткие диски позволили их вместить.

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

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

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

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

Фантастика? Не думаю.Отладочной платой просканирован верхний слой бедрока площадью 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 Второй цикл в среднем выполняется раза в два быстрее первого. Реальная разница будет не так сильно заметна, т.к. её будет размывать время выполнения других операций. Тут не просто +2 операции, это две операции в цикле. А +4 байта так и останутся всего лишь 4 байтами, которые так или иначе всё равно будут задействованы. Вопрос лишь в том, насколько важно их освободить по завершении цикла.Кроме +2 операций следует учесть задействование +2 переменных и +1 константы, что даже в ассемблере будет весьма заметно, не говоря уже о Lua с ее сложной системой доступа к переменным.

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

Учитывая нелюбовь других участников проекта к длинным текстам, сосредоточусь на самых злых моментах: 1) В цикле while not bedrock do scan() miner() end есть движения между найденными блоками руды, но нет возврата к центру столба. Полагаю, робот будет смещаться от центра столба, что приведет к недостаточно чистой копке. 2) Также мне видится довольно вероятной возможность нарваться на пустую площадку 7x7 в зоне бедрока. При текущей реализации выхода из нее к следующему столбу очень велик риск застрять в бедроке. Не вижу в коде обхода таких сюрпризов. 3) Этого и других крокодилов можно заметно укоротить: if d == 0 and dT == 1 or d == 1 and dT == 2 or d == 2 and dT == 3 or d == 3 and dT == 0 then turn(true) else turn() endНапример, так: turn((dT-d)%4==1)

Еще один замечательный алгоритм от danshat: 1) Выложи какаху и попроси не кидаться тапками; 2) Поешь жуков; 3) Объяви, что у тебя что-то готово, но результат не показывай; 4) Поешь еще этих мягких французских булок, да выпей же чаю.

Проблема в порочном алгоритме: 1) Задай вопрос; 2) Получи ответ; 3) Упрости решение, подстроив его под свой алгоритм; 4) Назови своё решение лучшим.

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

1) Координаты навигатора тоже относительные в радиусе 2048; 2) Программное плюсование координат необременительно даже по единичке; 3) Координаты стационарных локаций в память робота тоже нужно как-то вводить; 4) Относительный сдвиг до нужной позиции робот может вычислить самостоятельно и без бумажки. Достаточным будет лишь задать роботу стартовые координаты. Но он их забудет при выключении – это единственный недостаток программной навигации.

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

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

Лучше вообще лишнее не добывать. Экономится и время и энергия и ресурс инструмента. И серверу легче. А про код не буду писать, поберегу тапки

Нужно понимать, что computercraft.ru – площадка для изучения программирования через развлечение. И если не здесь развлекаться, то где же еще?

А это с какой стороны посмотреть. Может быть, os при ее редких вызовах и не стоит добавлять, тем более в такой простой программе. Но зато имеет смысл вынести из глобального окружения часто используемую библиотеку, даже если она стандартная. Можно и так: local math = require("math")но лучше так: local math = mathПричем, один раз выполненный require может и не внести ощутимой нагрузки, но повторяющиеся в цикле обращения к глобальному окружению увеличат постоянную нагрузку процентов на 10-20. По крайней мере, у меня были такие данные тестов.

Небольшое дополнение к сказанному @Zer0Galaxy output1,output2,output3 = table.unpack(output)для компактного присваивания значений таблицы целевым переменным.

Работает. Это бомба! Про теги давно уже думал и по разным поводам, но нагуглить так и не смог. Геолайзер я привёл в пример. Может, есть иные способы? Тем же анализатором или еще чем-нибудь? И роботы умеют ШПКМ, и ШПКМ пустой рукой по компьютеру включает его, но ШПКМ именно роботом почему-то не включает компьютеры, хотя и возвращает «true, block_activated». А было бы здорово. Проблема решилась доступом к NBT. Но твое предложение тоже интересно, я думал о нем в другом контексте. Но не смог поместить роботом плату в свой контейнер. Поделишься способом? У меня получилось засунуть плату только другим роботом, но это громоздко.

Думаю, нет смысла создавать новую тему. У меня набрались новые вопросы, связанные с периферией: 1. Можно ли узнать адреса компонент и блоков, просто лежащих в инвентаре робота? В инвентаре игрока адреса компонент доступны для просмотра. Для робота, лежащего в инвентаре робота, контролер инвентаря не выдает ни имени, ни адреса. Аналогично и для сетевой карты: просто сетевая карта, и всё. Реально ли вытащить адреса из тегов? 2. Может ли робот каким-либо образом узнать адрес соседнего блока? Например, геолайзер может сказать, что это робот, но не сообщает ни его имя, ни адрес. Анализатор при использовании игроком помещает сообщение в чат, но апргейд чата из Computronics его не ловит. Анализатор при использовании роботом вообще ничего не показывает, и апргрейд чата опять же ничего не получает. 3. Может ли робот включать или выключать стоящие рядом компьютеры иным путем кроме как через wake-up по редстоун- или сетевой карте? Черепахи, насколько я помню, умели это делать. И компьютер легко включает роботов, а наоборот – не получается. 4. Можно ли как-то узнать адрес адаптера, через который подключено устройство, и сторону, с которой устройство находится относительно адаптера?

Я хотел акцентировать внимание не на том, от чего следует уйти, а на том, куда желательно прийти. Все мы говнокодим в начале пути: сначала пелёнки пачкаем, потом ломаем инструменты на уроках труда, залагиваем сервер майнкрафта, заплёвываем какахами своих оппонентов по форуму, и даже превращаем в брак целые партии продукции на заводе. Почти все понимают, что это плохо, но не у каждого получается этого избежать. Кто-то не знаком с теорией, у кого-то не достаточна практика, а кому-то нужен практический совет и живой пример. Последнему и посвящена запись моего блога. Или у тебя возникло чувство, что мой текст недостаточно длинный?

Так-то всё можно, да не всё полезно. Таблицу локальной делать не обязательно, но, как правило, желательно. И оператор goto тоже можно использовать, да граблей там разбросано много.

О, классная тема, qwertyMAN! Спасибо, что напомнил мне опубликовать позабытый текст. Заходи на огонек. пп.1,3: Krutoy уже всё объяснил. Высосано из пальца. Следует исходить из требований задачи, а если они тебя не ограничивают – то из личных предпочтений. пп.2,4: Тема комментариев весьма противоречива и холиварна. Во-первых, комментировать код следует настолько, насколько это помогает самому автору впоследствии разобраться в своей же программе. Новички склонны комментировать элементарные действия, а более опытные программисты комментируют блоки покрупнее, поясняя алгоритм или структуру программы. Также имеет смысл комментировать всякие нестандартные трюки. Впрочем, для кого-то использование числа вместо булевой переменной – вполне рутинный подход. Во-вторую очередь код нужно комментировать так, чтобы он был понятен потенциальному читателю. Читатель бывает разный, на каждого не угодишь, поэтому в случае сомнений думай в первую очередь о том, сможешь ли ты сам быстро понять свой код, например, через год. Дилемма: использовать длинные и легко читаемые названия переменных или же использовать короткие, один раз прокомментировав их? Я в небольшом проекте предпочитаю короткие названия с комментариями: код короче, и читается быстрее. В проекте с большим количеством переменных удобны более длинные названия переменных. Но опять же, всё относительно. Есть, например, ООП, пространства имен и прочее, позволяющие уменьшить количество переменных в зоне видимости. В целом спорные советы, смущающие новичков. Только к глобальным переменным нет вопросов. И нет ничего плохого в написании кода в обычном блокноте или даже в редакторе OpenOS. Мазохизм, конечно, но есть любители, сделавшие свой выбор осознанно.