Ехал бы тот, кто ближе к человеку с учетом очереди задач. Не думаю, что в этой задаче оптимизации нашлось бы что-то новое из того, что не решается давно придуманными алгоритмами.
Хотя описание задачи, приведенной в посте, явно потеряло какие-то важные детали. О какой неопределенности идет речь? Как происходит обмен информацией между роботами? Если при нажатии кнопки заказ «по воздуху» поступает в централизованную очередь заказов, то сложность задачи не ясна. Первый робот, который подъезжает к бармену за пивом в определенную комнату, забирает все пиво, которое ждут в той комнате.
Вероятно, они обмениваются информацией только при контакте (причем, например, только с барменом). Но тогда официант подъезжает к бармену, забирает одну банку и везет туда, где взял заказ. Возможность одновременной доставки нескольких заказов могла бы быть только при одновременном возвращении двух роботов из одной комнаты.
Остается вариант, что все эти роботы кружат-кружат-кружат по комнатам, собирают пачки заказов, а по возвращении носят заказы отдельно для каждой комнаты. То есть очередь заказов остается. Но при таком раскладе не лучше бы было разделить между роботами зоны ответственности (за каждым официантом закреплены отдельные столы) с попутной реализацией распределения нагрузки?
Дайте угадаю вы хотели повторить это? valplo: Что это, Бэрримор?! withkittens: Это реабилитационный пост от пользователя с отрицательной кармой, сэр. valplo: И что он тут делает, Бэрримор? withkittens: Собирает минусы, сэр.
Там и первый вариант — тоже шестиугольники, только на две части разрезанные. И тоже можно было сделать более наглядно, но, видимо, целью было наоборот скрыть простоту решения. Не знаю, зачем.
Без пояснительных рисунков, объяснений того, что из себя представляет угол в 180°, и прямого указания на то, что не надо все настолько серьезно воспринимать, видимо, посетители GT не способны оценить комментарий. Сейчас еще и выяснится, что предыдущее предложение оказалось слишком сложным для них.
Я правильно понимаю из ваших результатов, что CJSON при этом в ~40 раз эффективнее по памяти? И тут встает вопрос выбора между более быстрым и более экономным по памяти решением. А вы как-то очень уж однозначно в сторону скорости выбираете, выходит.
На выходе нужен был JSON. Видимо, поэтому авторы и подумали, почему бы не сделать его и на входе. Требовалось расширить имеющийся инструмент. Объектом вдохновения могли быть, например, препроцессоры CSS: человек, знакомый с CSS, разберется с препроцессором в мгновение ока. Но одно дело — развить формат описания данных в расширенный формат описания данных или расширить язык программирования до языка программирования с большими возможностями. И совсем другое — расширить формат описания данных до языка программирования.
В простейших случаях, возможно, доля удобства в этом и будет, но только в них. Конструкции получаются громоздкими, а решения проблем, обозначенных как предпосылки к созданию нового языка, я не увидел.
То есть предполагается вместо лечения гриппа применять профилактику осложнений? Если не удается бороться с причиной, то ударить по следствиям. Интересно. На как-то все скомканно: раньше не догадывались так делать или просто не было способа для этой самой профилактики (лекарства)?
Я вас, возможно, немного расстрою, но на странице оригинала большими буквами написано «Available in English, Russian» со ссылочкой на перевод и на гитхаб.
Хотя описание задачи, приведенной в посте, явно потеряло какие-то важные детали. О какой неопределенности идет речь? Как происходит обмен информацией между роботами? Если при нажатии кнопки заказ «по воздуху» поступает в централизованную очередь заказов, то сложность задачи не ясна. Первый робот, который подъезжает к бармену за пивом в определенную комнату, забирает все пиво, которое ждут в той комнате.
Вероятно, они обмениваются информацией только при контакте (причем, например, только с барменом). Но тогда официант подъезжает к бармену, забирает одну банку и везет туда, где взял заказ. Возможность одновременной доставки нескольких заказов могла бы быть только при одновременном возвращении двух роботов из одной комнаты.
Остается вариант, что все эти роботы кружат-кружат-кружат по комнатам, собирают пачки заказов, а по возвращении носят заказы отдельно для каждой комнаты. То есть очередь заказов остается. Но при таком раскладе не лучше бы было разделить между роботами зоны ответственности (за каждым официантом закреплены отдельные столы) с попутной реализацией распределения нагрузки?
valplo: Что это, Бэрримор?!
withkittens: Это реабилитационный пост от пользователя с отрицательной кармой, сэр.
valplo: И что он тут делает, Бэрримор?
withkittens: Собирает минусы, сэр.
В простейших случаях, возможно, доля удобства в этом и будет, но только в них. Конструкции получаются громоздкими, а решения проблем, обозначенных как предпосылки к созданию нового языка, я не увидел.