В FCOM на B737, например, выпуск закрылков идёт в разделе Before Taxi и в нём предполагается, что двигатели уже запущены, так как перед закрылками идёт отключение APU и перевод стартеров в режим взлёта/посадки (CONT).
напомню, что авиакатастрофа - это когда самолет покоцан достаточно, чтобы получилась хотя бы одна жертва
Тогда введём понятие "автокатастрофа" - ДТП, при котором есть хоть один погибший, - и сравним вероятности. Ну либо для авиации тоже надо брать все происшествия, те же выкаты за полосу или задевание крылом на рулёжке.
Структура памяти остается плоской (агглютинативной)
Не остаётся. Прочитайте спецификацию. Ещё раз прочитайте спецификацию. Смещения во FlatBuffers формируют древовидную структуру. Первое смещение даёт адрес экземпляра. Затем первое поле в экземпляре - отрицательное смещение на vtable. В vtable записано количество полей и их смещения внутри экземпляра. При этом порядок, типы и размер полей определяются заранее, при разработке протокола. Если поле строковое, то оно содержит смещение в таблице строк. Теперь попробуйте соотнести это с вашей "агглютинативной" идеей.
Это и есть та самая линейная сложность без возвратов и рекурсий.
Она линейная для одного поиска. Как только вам надо выбрать несколько полей, вам придётся либо строить каталог, то есть тратить дополнительную память, либо выполнять поиск для каждого поля, то есть общая сложность станет квадратичной.
отказ от вложенных, рекурсивных (флективных) структур данных в пользу плоских, линейно-размеченных буферов (агглютинативных)
Как только у вас данные начнут усложняться, вы всё равно вернётесь к древовидному представлению, в той или иной форме. Попробуйте агглютинативно описать следующую структуру данных:
Посмотрите на FlatBuffers или Cap'n Proto (и отчасти на концепцию TLV — Type-Length-Value). В их основе лежит именно агглютинативный паттерн: есть неизменный корень (указатель/ID сущности), к которому линейно, друг за другом, "приклеены" блоки данных с фиксированным смещением.
А вы сами читали спецификации этих форматов? Там нигде нет фиксированных смещений элементов. Во FlatBuffer смещение на смещении сидит и смещением погоняет. Чтобы добраться до нужного элемента надо прочитать 3-5 смещений. А чтобы существенно сменить схему данных необходимо согласовать изменения на обоих сторонах протокола. В Cap'n Proto вообще создаются функции сериализации/десериализации на C++ для каждой версии схемы. В TLV у вас ни порядок элементов, ни смещения в общем случае не фиксированы и требуют либо составления каталога элементов для каждого экземпляра, либо поиска нужного элемента просмотром всех с начала сообщения. И во всех случаях вы завязаны на машинозависимый размер и порядок байтов. То есть, обмен между разными архитектурами будет затруднён.
При этом, чтобы отладить обмен вам для бинарных протоколов понадобится отдельный софт, позволяющий визуализировать сообщение и создать сообщение из введённых вручную данных.
Однако, большинство программ полагают, что этот поток, как минимум, разбит на строки, то есть частично структурирован. Если вы пошлёте в grep поток без разделителей строк, то он всё равно будет считать, что там есть одна строка, состоящая из целого потока. И awk, и sed, и sort и многие другие программы предполагают строковое структурирование потока. Но, для той же awk или sed только строк обычно недостаточно. И, как только вам надо выделить внутри строки ещё какую-либо структуру (поля), вам приходится заниматься магией, описывая разделители, номера нужных полей, что-то ещё - то есть заниматься структуризацией этого потока. А как только мы переходим от программ общего назначения к специализированным, принимающим на входе и выдающим на выходе конкретные, заранее определённые, данные, каждый раз структурировать текстовый поток становится неудобно. Поэтому для обмена такие программы используют согласованные между собой представления данных, те же JSON, XML, BinaryObject и т.п.
чтобы разные модули могли стыковаться без адаптеров
Например, как вы состыкуете модуль, возвращающий прогноз погоды на три дня с модулем, принимающим расписание уроков? Ну да, можно выдать прогноз в виде строк текста и затем попытаться интерпретировать их как расписание. Но будет ли в этом смысл? Если два модуля обмениваются конкретной информацией, то нет смысла закладывать для них мегауниверсальный протокол обмена. Достаточно выбрать формат, например JSON, и описать структуру данных обмена в этом формате. А если у вас система из сотни модулей, общающихся между собой, то есть смысл выбрать единый формат (не конкретную структуру, а именно формат), позволяющий удобно описать все структуры межмодульной коммуникации. И в разных системах этот формат может быть разным, от распространённого JSON до кастомного бинарного, как это удобно разработчикам.
Справка отдела военного машиностроения Госплана при СНК СССР: «Уровень себестоимости главнейших изделий оборонной продукции по Наркомату авиационной промышленности СССР»
http://rgae.ru/avia-prom.shtml/09.shtml
Как видите, к маю 1942 года себестоимость Як-1 упала ниже 100000 рублей.
Денежная реформа 1947 проводилась 1:1, менялись только купюры, номиналы и цены не затрагивался. Денежная реформа 1961 проводилась 10:1. Так что цена Як-1 была 10000 "хрущёвских" рублей.
За несколько дней Ферапонт Петрович собрал мешок денег (мёд был очень дорогой — 1 кг стоил 500—900 руб., а в тот год Ферапонт Головатый собрал 200 кг мёда), после чего пришёл к директору Саратовского авиазавода Израилю Соломоновичу Левину с просьбой продать ему истребитель, оцененный им в 100 тысяч рублей.
«Военный совет ВВС сердечно благодарит Ф.П. Головатого за его патриотический почин. Деньги просим внести в госбанк, в фонд обороны. Копию квитанции вручить военпреду завода. Выделить один из облетанных самолётов Як-1, написав на фюзеляже то, что просит колхозник».
Кстати, автомобили в СССР приобретали аналогичным образом. Выписывался чек, деньги вносились в сберкассе, по квитанции из сберкассы выдавался автомобиль.
Атомную бомбу тоже наверное можно было купить?
А сейчас, при всём расцвете капитализма и удовлетворении потребностей можно купить атомную бомбу?
А можно сказать, что Головатый купил самолёт в подарок Борису Ерёмину. А экипаж Георгия Чайко летал на штурмовике ИЛ-10, на борту которого была надпись "Куплен на личные сбережения экипажа". Это будет "купили" или нет?
– Нет, серьезно. Он там управлял системой подземки – никаких нареканий, идеальный работник, а потом однажды эта штука просто забыла запустить вентиляторы, когда было надо. Поезд заезжает на пятнадцать метров под землю, пассажиры выходят, воздуха нет, бум! ... – Эти штуки вроде как учатся на собственном опыте, правильно? – продолжает Джарвис. – Ну и все думали, что зельц научился запускать вентиляторы по какому‑то очевидному признаку. Жару тела, движению, уровню углекислого газа, ну ты понимаешь. В результате выяснилось, что эта хрень просто смотрела за часами на стене. Прибытие поезда совпадало с предсказуемым набором паттернов на цифровом дисплее, поэтому она включала вертушки, когда видела один из них. – Ага. Точно, – Джоэл качает головой. – А какие‑то вандалы часы разбили. Или что‑то вроде того.
Ну, истребитель, например. В 1942 году колхозник Головатый купил за свои деньги Як-1 для фронта (продав два центнера мёда с личной пасеки), а в 1944, когда этот самолёт признали негодным, купил Як-3. Як-1, кстати, оценивался в 100000 рублей. А ЗИС-101 перед войной стоил 27000 рублей и желающих купить было достаточно, так что продавался он по разрешениям. Вполне сравнимые цены.
нужен цех и 100 станков - нужно запланировать 100 рабочих
В году 52 недели. Из них 4 (а на севере 6) работник в отпуске. Работник может заболеть, может неожиданно умереть. Вам в любом случае нужен запас порядка 10-15%.
Зарплату им не заплатят (они же не работали)
А, скажем, пожарным надо платить зарплату, если пожаров не было? Они же не работали.
А те, кто варил кашу на молоке перейдут на яичницу с беконом. А те, у кого была яичница с беконом перейдут на что-то ещё более деликатесное, раз уж всё подешевело. Так что не факт, что потребление молока вырастет.
То есть станете съедать в 10-20-100 раз больше крупы, если цена упадёт? Выпивать в 10-20-100 раз больше молока? У потребления еды есть физиологический лимит. При этом, если вся (в том числе и деликатесная) еда подешевеет, то в дешёвых категориях продажи могут упасть за счёт перемещения фокуса на более дорогие продукты.
Ну, в середину экрана курсор надо приводить сознательно, а в крайнее достаточно двинуть мышкой посильнее, можно даже не глядя на экран.
В FCOM на B737, например, выпуск закрылков идёт в разделе Before Taxi и в нём предполагается, что двигатели уже запущены, так как перед закрылками идёт отключение APU и перевод стартеров в режим взлёта/посадки (CONT).
Страница FCOM
Тогда введём понятие "автокатастрофа" - ДТП, при котором есть хоть один погибший, - и сравним вероятности.
Ну либо для авиации тоже надо брать все происшествия, те же выкаты за полосу или задевание крылом на рулёжке.
Не остаётся. Прочитайте спецификацию. Ещё раз прочитайте спецификацию. Смещения во FlatBuffers формируют древовидную структуру. Первое смещение даёт адрес экземпляра. Затем первое поле в экземпляре - отрицательное смещение на vtable. В vtable записано количество полей и их смещения внутри экземпляра. При этом порядок, типы и размер полей определяются заранее, при разработке протокола. Если поле строковое, то оно содержит смещение в таблице строк. Теперь попробуйте соотнести это с вашей "агглютинативной" идеей.
Она линейная для одного поиска. Как только вам надо выбрать несколько полей, вам придётся либо строить каталог, то есть тратить дополнительную память, либо выполнять поиск для каждого поля, то есть общая сложность станет квадратичной.
Как только у вас данные начнут усложняться, вы всё равно вернётесь к древовидному представлению, в той или иной форме. Попробуйте агглютинативно описать следующую структуру данных:
Единственно верного пути, как обычно, не существует. В каждом варианте есть свои плюсы, свои минусы, свои оверхеды. how-standards-proliferate.jpg
А вы сами читали спецификации этих форматов? Там нигде нет фиксированных смещений элементов.
Во FlatBuffer смещение на смещении сидит и смещением погоняет. Чтобы добраться до нужного элемента надо прочитать 3-5 смещений. А чтобы существенно сменить схему данных необходимо согласовать изменения на обоих сторонах протокола.
В Cap'n Proto вообще создаются функции сериализации/десериализации на C++ для каждой версии схемы.
В TLV у вас ни порядок элементов, ни смещения в общем случае не фиксированы и требуют либо составления каталога элементов для каждого экземпляра, либо поиска нужного элемента просмотром всех с начала сообщения.
И во всех случаях вы завязаны на машинозависимый размер и порядок байтов. То есть, обмен между разными архитектурами будет затруднён.
При этом, чтобы отладить обмен вам для бинарных протоколов понадобится отдельный софт, позволяющий визуализировать сообщение и создать сообщение из введённых вручную данных.
Однако, большинство программ полагают, что этот поток, как минимум, разбит на строки, то есть частично структурирован. Если вы пошлёте в grep поток без разделителей строк, то он всё равно будет считать, что там есть одна строка, состоящая из целого потока. И awk, и sed, и sort и многие другие программы предполагают строковое структурирование потока.
Но, для той же awk или sed только строк обычно недостаточно. И, как только вам надо выделить внутри строки ещё какую-либо структуру (поля), вам приходится заниматься магией, описывая разделители, номера нужных полей, что-то ещё - то есть заниматься структуризацией этого потока.
А как только мы переходим от программ общего назначения к специализированным, принимающим на входе и выдающим на выходе конкретные, заранее определённые, данные, каждый раз структурировать текстовый поток становится неудобно. Поэтому для обмена такие программы используют согласованные между собой представления данных, те же JSON, XML, BinaryObject и т.п.
Например, как вы состыкуете модуль, возвращающий прогноз погоды на три дня с модулем, принимающим расписание уроков? Ну да, можно выдать прогноз в виде строк текста и затем попытаться интерпретировать их как расписание. Но будет ли в этом смысл?
Если два модуля обмениваются конкретной информацией, то нет смысла закладывать для них мегауниверсальный протокол обмена. Достаточно выбрать формат, например JSON, и описать структуру данных обмена в этом формате. А если у вас система из сотни модулей, общающихся между собой, то есть смысл выбрать единый формат (не конкретную структуру, а именно формат), позволяющий удобно описать все структуры межмодульной коммуникации. И в разных системах этот формат может быть разным, от распространённого JSON до кастомного бинарного, как это удобно разработчикам.
До хрущёвского разгона артелей и кооперативов вполне себе конвертировались.
Справка отдела военного машиностроения Госплана при СНК СССР: «Уровень себестоимости главнейших изделий оборонной продукции по Наркомату авиационной промышленности СССР»
Как видите, к маю 1942 года себестоимость Як-1 упала ниже 100000 рублей.
Денежная реформа 1947 проводилась 1:1, менялись только купюры, номиналы и цены не затрагивался.
Денежная реформа 1961 проводилась 10:1.
Так что цена Як-1 была 10000 "хрущёвских" рублей.
Кстати, автомобили в СССР приобретали аналогичным образом. Выписывался чек, деньги вносились в сберкассе, по квитанции из сберкассы выдавался автомобиль.
А сейчас, при всём расцвете капитализма и удовлетворении потребностей можно купить атомную бомбу?
А можно сказать, что Головатый купил самолёт в подарок Борису Ерёмину.
А экипаж Георгия Чайко летал на штурмовике ИЛ-10, на борту которого была надпись "Куплен на личные сбережения экипажа". Это будет "купили" или нет?
Напрямую у производителя, без посредников.
Потому что план составляется исходя не только из потребностей, но и из возможностей.
(C) Питер Уоттс. Рифтеры.
Ну, истребитель, например. В 1942 году колхозник Головатый купил за свои деньги Як-1 для фронта (продав два центнера мёда с личной пасеки), а в 1944, когда этот самолёт признали негодным, купил Як-3.
Як-1, кстати, оценивался в 100000 рублей. А ЗИС-101 перед войной стоил 27000 рублей и желающих купить было достаточно, так что продавался он по разрешениям. Вполне сравнимые цены.
А теперь пусть нарисует спидометр, манометр и 24-часовой морской хронометр.
Так при рыночной экономике вам тоже нужен этот оверхед по работникам, они ходят в отпуска и болеют независимо от плановости.
А при рыночной экономике им надо зарплату платить или нет?
В году 52 недели. Из них 4 (а на севере 6) работник в отпуске. Работник может заболеть, может неожиданно умереть. Вам в любом случае нужен запас порядка 10-15%.
А, скажем, пожарным надо платить зарплату, если пожаров не было? Они же не работали.
А те, кто варил кашу на молоке перейдут на яичницу с беконом.
А те, у кого была яичница с беконом перейдут на что-то ещё более деликатесное, раз уж всё подешевело.
Так что не факт, что потребление молока вырастет.
То есть станете съедать в 10-20-100 раз больше крупы, если цена упадёт? Выпивать в 10-20-100 раз больше молока?
У потребления еды есть физиологический лимит. При этом, если вся (в том числе и деликатесная) еда подешевеет, то в дешёвых категориях продажи могут упасть за счёт перемещения фокуса на более дорогие продукты.
Если дочитать задачу до конца, то увидите
Но навык чтения - это тоже древнее забытое искусство.