eu_tomat

А разве передатчик никогда не выдает единицу?

Хотя, нет. Спрошу иначе. Почему твой передатчик никогда не выдает единицу?

Целочисленное деление

 

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

-- в цикле передатчика:
l = l - 10^(n-1)

-- в цикле приемника:
l = l +10^ (r.getInput(s.left)-1)
if r.getInput(s.left)==1 then l=l+1-0.1  -- зачем ты что-то добавляешь к результату?

-- вывод результата приемника
print((l-l%10)/10) -- зачем делишь его на 10?

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

1) Какое-то деление результата на 10;

2) Добавление к результату 0.9 в тех циклах, когда уже было добавлено 1.0, т.е. 9 раз;

3) Добавление к результату 0.1 во всех циклах, т.е. в твоем случае 14*9 раз.

 

Quant, ты хотя бы проверял работу своего кода? Что выводил приемник?

Теперь прога работает ещё быстрее - числа в 14 цифр из девяток(99999999999999) передаются 14*9*2 тиков

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

И еще проясни смысл вот этой строки в конце принимающей части

print((l-l%10)/10)

О, как! Сошлись две противоборствующие стихии: одна удушает нас клубком труб из AE, а другая не оставляет нам ничего кроме чистого космоса и единственной дебаг-карты.

 

Если ты думаешь, что AE - скучный мод, то ты его толком не знаешь. Мне он кажется интересным т.к. там есть возможность "побыть инженером", составляя сложную, запутанную схему обработки предметов у себя дома.

Ты правильно сделал, взяв фразу "побыть инженером" в кавычки, потому что будучи настоящим инженером ты бы не городил сложных и запутанных схем на основе работающего на магии AE, а собрал бы простую и эффективную на основе прозрачно работающих компьютеров. Кстати, AE2 был усложнен специально, т. к. первый оказался слишком скучным. Но похожая на реальную сложность логистики была заменена надуманной сложностью ограничения каналов в кабеле. Но не следует говорить, что это сложный мод, т.к. все его сложности преодолимы чтением вики и аккуратной расстановкой блоков, выливающейся в конечном итоге в сложные и запутанные схемы. Doob, похоже, понял, что подобные схемы автоматизации являются тупиком, но ушел в другую крайность, где инженерия становится бессмысленной.

Злобный движок форума не дает добавлять цитаты даже следующим сообщением. Напишу иначе.

 

Doob: Автокрафт у меня есть, рецепты забивать лень.

Если тебе лень забивать рецепты, то о каком автокрафте ты говоришь?

Doob: Я, к примеру, специализируюсь на селекции, если кто-нибудь может мне сказать, как робот будет анализировать семена, то можно сделать автоматическую ферму селекции.

А мне интересно, почему на сервере, где во главу угла поставлена автоматизация, ты выбрал для себя принципиально неавтоматизируемую специализацию? Кстати, способ автоматизации есть, но не на этом сервере.

 

Doob:

почему все думают, что это виртуализация?

…

Представьте, что предметы отправляются в какое-то реальное хранилище, реальные устройства при помощи Ender технологий, просто к ним нет физического доступа, т.к. они находятся в другом мире.

 

Если единственным способом увидеть хранилище является включение воображения, то такое хранилище виртуально. А для того, чтобы просто не видеть реальное хранилище, достаточно в него не заходить и не строить его. Твой робот сам построит комнату для склада, разместит в ней сундуки, и по мере необходимости будет увеличивать их количество и выполнять их апргейды. Ты не видишь склад, а он есть. Но при желании ты всегда можешь его увидеть в отличие от виртуального.

 

А так ты начал с виртуального склада, добавил виртуальный крафт, для которого тебе пока еще лень забивать рецепты, потом добавишь виртуальные печки, которые сами переплавят руду, добавишь виртуальную селекцию, окончания которой нужно просто подождать, добавишь виртуальных шахтеров, которым не требуется куда-либо ехать за рудой. Но всё это уже есть! В креативе. Просто, когда будешь брать нужную машину из NEI, представь, что в другом измерении трудится реальный шахтер, он добыл руду, кинул ее в дробилку-очищалку-плавилку, скрафтил для тебя машинку, и теперь ты держишь ее в руках. Хотя, постой! Зачем тебе эта машинка, когда у тебя давно уже есть целый завод в другом измерении? И зачем тебе броня, если тебе даже из дома выходить не требуется?

Зачем тебе майнкрафт, если можно играть в своем воображении? Просто представь, что у тебя уже всё есть.

 

 

Подозреваю, что где-то в логике обработки столкновений с монстрами и гравием есть недочет.

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

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

• Не нравится AE? AlexCC давно уже показал альтернативу: сундуки + робот. Сердцем системы будет таблица крафтов, но она потребуется в любом случае. Еще нужно будет помнить, что и в каком сундуке лежит, но для робота это не будет проблемой.
• Покупать и продавать предметы, не прыгая до банка — читерство.
• Любая виртуализация логистики — зло для игрока. Система транспортировки в AE — тоже скучная. Делать свою AE на дебаг-карте — еще большее зло. В чем тогда будет прелесть игры?
• Обмен товарами "как в реальном мире" — интересная идея, но при чем тут дебаг-карта?
• И, кстати, на чем на таком "своем" может специализироваться игрок? Выращивание картошки? Так едой любой игрок сам себя обеспечивает. Давно уже написаны шахтеры, лесорубы и фермеры. Качай программу, устанавливай на робота и забудь о любой зависимости от любого товара. Сельхозпродукция в майнкрафте почти сразу становится мусором. Как только ты построишь приличного робота-шахтера, мусором становятся и руды тоже. Тебе скучно быть фермером? Есть решение — нескучный робот-фермер. Тебе скучно строить помещение под ферму? Есть решение — нескучный робот-строитель. Все равно скучно? Напиши веселого робота-кладовщика.

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

• В каких единицах измеряется скорость?

-скорость где-то в 11 раз больше(1000 за 42сек.)

1000 чего?

• Алгоритм кодирования очень странный: передатчик разделяет число на слагаемые, а приемник суммирует. О какой производительности тут можно говорить? Тут уже предлагали разделить число на пятнадцатеричные разряды, такой подход значительно сократит длину передачи.
• Скорость можно дополнительно увеличить в два раза, избавившись от бессмысленной передачи нуля. Зачем передавать ноль, когда можно передать полезную информацию?
• Использовать два и более сигнальных провода — тупиковый путь. При таком подходе проводов всегда будет мало. Использование дополнительных проводов оправдано только в случае полного использования пропускной способности одного.
• Рассказ про шину на компараторах тут интересен только в контексте двоичного кодирования, но в данном случае более оптимальным будет использование пятнадцатеричного.
• Код Грея вообще не приносит пользы в решении этой задачи, он полезен только в реальном мире и только для двоичных кодов.
• Кстати, не следует идеализировать реальный мир. В майнкрафте есть лаги, зато в реальном мире к лагам добавляются шумы и потери сигнала. И без коррекции ошибок там никак не обходится кроме простейших случаев.
• Предложение реализовать UART мне нравится, но не следует делать утверждений о том, что все способы цифровой передачи сводятся к отсутствию или наличию сигнала. Для понимания этого достаточно ознакомиться со способами кодирования сигнала в модемах. Не погружаясь в детали, скажу, что сигнал имеет несколько состояний, и их количество значительно больше двух. Не принимать их во внимание — значит неэффективно использовать особенности среды передачи данных

Резюмирую. Передача по связке кабелей банальна, UART тоже скучноват, передача данных по одному редстоун-каналу с его 16-ю состояниями выглядит весьма интереной, и в текущем решении потенциал редстоуна совсем не раскрыт. А его раскрытие мне кажется увлекательным. Конечно, для начала и UART сойдет. Но 16 уровней сигнала против двух — это совсем другие возможности.

Сегодня игрался со своими интерактивными автономными фаланговыми геосканерными робо-копалками в одиночке и натолкнулся на факт наличия квитанции от командного блока.

Просто интересно: А зачем копалкам нужен командный блок?

Если абракадабру почитать на ночь, и уснуть, положив два кусочка медного провода под подушку, то наутро абракадабра станет менее кадабристой.

Хороший подход. Перед сном по чайной ложке знаний каждый день.

В таком случае я предлагаю понизить цену в тугриках для КСП на процентов 25-30%, повысить цену в кредитах на гибридку на 400%, на ультимку повысить цену в кредитах до 2кк. Продвинутая буровая на мой взгляд слишком дешева по кредитам, квантовые шмотки понизить цену в тугриках на 100 единиц... P.S.  Байт меняла в загуле уже дня три...

Артем, слишком явно в твоих предложениях проглядывает система: снижаем цену в тугриках, увеличиваем цену в кредитах.

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

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

Я в замешательстве. С одной стороны, надо поощрить активность новичков. А с другой, хороший раздел превращается в свалку HelloWorld'ов, написанных для попадания в вайтлист. Может быть, стоит вынести такие явно учебные программы в другой раздел? Тогда и старания новичков сохранятся в истории, и раздел не будет замусорен.

Вижу, одна ошибка исправлена. Все равно платформа строится неправильной формы.

Рисунок из символов это тру олдскул )

Тут даже олдскул не помог внести ясность - вот, в чем проблема.

Не части. У тебя еще первая программа не заработала, как ты заявлял, а уже за вторую взялся. Код этой даже смотреть не буду. Наверняка и здесь те же проблемы.

Еще раз взглянул на код. Программа НЕРАБОЧАЯ. Нечего ей делать в этом разделе. Есть как минимум две ошибки.

Код есть,вставил

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

1) Для лучшей читаемости кода делай отступы;

2) Сделай возможность задавать размер платформы через параметры;

3) Опиши условия, при которых твоя программа сохраняет работоспособность, а при каких нет.

 

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

Когда-то я тоже писал такую программу.

Но не смог опубликовать по техническим причинам.

А ведь мог бы сейчас медальку носить.

Все эти программисты тоже ходят с костылями?

P.S. О тонкостях использования тернарного оператора поясняется тут. Просто не подаешь нилы вторым выражением и не паришься.

Последняя ссылка великолепна. Теперь понял, спасибо за разъяснение.

Пожалуй, не буду называть эту конструкцию костылем. В конце концов, в Lua есть нога «if then else». Назову это прыжковыми ходулями. Они тоже расширяют возможности, но при определенных ограничениях. Вот, отсутствие оператора continue в Lua огорчает меня значительно больше.

 

P.S.: Ты мало того, что Крутой, так еще и хитрый. Чтобы рассказать нам про замену тернарного оператора в Lua, сделал вброс про какие-то подводные камни, которые на самом деле были очевидными, заставил меня спорить с тобой. Но план сработал. Возьму на вооружение.

У меня тоже похожие чувства когда только начинал на Lua, особенно когда боялся измерять длину массива через # - а вдруг там есть nil в середине. Но со временем отпустило. И тебя как нибудь отпустит от предубеждений.

А вот здесь ты круто завернул. Зачем ты упомянул получение длины массива через #? Это штатная конструкция языка. А приведенная тобой является костылем, после использования которого ты же сам заявляешь, что он не работает, как настоящая нога. А разве должен был? И с каких пор хождение на штатных ногах стало считаться предубеждением?

 

Но повторюсь, ошибка возникает не из-за игнорирования правил приоритета а из-за неверного прочтения конструкции.

Согласен. Меня смутил твой код, который явно нарушал приоритет и при этом якобы подтверждал слова Крутого об аномалии. И я решил, что вы оба делаете одну ошибку.

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

По твоей теме не отвечу, нет полномочий.

В луа выражение "а and b or c" является заменой строчного условного оператора "a ? b : c" в других языках, например С++, за исключением случая, описанного мной.

С этим соглашусь полностью, но не стоило называть это аномалией. Lua не имеет полноценного тернарного оператора.

А лучше назовем вещи своими именами. Эта конструкция является костылем, который не всегда помогает пациенту.

Я сам пишу if(a) then x=b else x=c end. Выглядит не столь компактно, но работает безотказно. Твой же вариант тоже далек от изящества оригинала. Я бы избавился от такой конструкции, т.к. однажды замучаешься искать ошибку в коде.

То бишь, это будет, как сказал Крутой, "если а возвращать b, иначе c", но не дай бог b будет false/nil.

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

Перефразирую короче. Выражение (a and b or c) следует читать как ((a and b) or c)

Очевидно, что в этом случае при b==false и b==nil всегда будет возвращаться c

 

And стоит перед or. Он и так выполняется первым. Правила приоритета не применяются и никак не влияют на результат.

Еще как применяются. Первенство играет роль только для операций с одинаковым приоритетом.

Твой же вариант раскрытия возможен, если отдать приоритет операции or над and:

Нужно читать "Если А истинно, то вернуть B или С, иначе вернуть А"

Я бы мог неверно истолковать твои слова, но ты подтвердил их кодом.

 

А чем руководствовался Krutoy, раскрывая это выражение, я вообще не понял.

О, понял! Он пытается использовать эту конструкцию как тернарную операцию. Но почему именно так, все равно не понял.

Приоритет здесь не при чем.

Прошу обосновать это утверждение.

А еще, вот какой есть подводный камень:

return a and b or c

Казалось бы, "если а то вернуть b иначе c", но при этом если b == nil или false то всегда возвращает с.

 

Этот камень очень даже надводный. Во всех известных мне языках программирования операция and имеет приоритет над or. Соответственно, (true and b)==b, а учитывая твои условия, (true and b or c)==c.

Ну, точно же! Робот с булыжником в инвентаре и геосканер. Будем хранить инфу в толще породы.

Можно и без геосканера обойтись. Только скорость чтения сильно упадет.