Разные полиномы дают разные характеристики обнаружения ошибок. Т. е. полином 0xf8c9140a, который обнаруживает 8 ошибок на данных до 992 бит, обнаружит и меньшее количество ошибок, но вот полином 0xad0424f3, обнаруживающий три ошибки на данных до 4294967263 бит, может и не заметить 8 ошибок. Также полином 0xf8c9140a, который обнаруживает 8 ошибок на данных до 992 бит, на большем кодовом слове действительно может не обнаружить ошибок вообще.
Проблема английского как раз в том, что это далеко не легковесный язык. А Эсперанто приспособился к тому, что миру такой общий язык общения не нужен и просто живёт среди энтузиастов.
одни говорят: зачем столько языков (человеческих)? Давайте сделаем один универсальный! Эсперанто! Он лучше любого.
У Эсперанто немного другая задача: это легковесный fallback-язык, который не заменяет родные языки, а позволяет общаться, когда у собеседников нет совпадения по родным языкам.
И это печально, что такой более совершенный метод не используется. C таймаутами возникает проблема по полной утилизации линии, а с преамбулами, как я писал выше, встречал странные алгоритмы восстановления синхронизации.
Обработка ошибок это уже не канальный уровень. А работать с кадрами, для которых уже определена граница и целостность (при адекватной длине и CRC), гораздо удобней.
Сравнивал я с определением границ кадра по преамбуле, с определением границы по таймауту, с использованием длины данных в заголовке. Эти все варианты зачастую порождают сложные эмпирические алгоритмы по восстановлению/синхронизации, теряют корректные кадры, если предыдущие потеряли символ. Контролируемая избыточность это сильный аргумент: простые алгоритмы байт-стаффинга могут привести к удвоению размера всего кадра, а это и лишняя память под буферизацию, искажение временных характеристик -- это не дело, когда в зависимости от содержимого кадры передаются за разное время. В COBS, например, максимальные затраты это 1 байт на 254 байта исходного кадра. Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
На мой взгляд использовать байт-стаффинг для канального уровня гораздо лучше, чем альтернативы: не надо знать заранее размер передаваемых данных; границы пакета всегда чётко определены; если использовать COBS, избыточность контролируема; подходит под любые скорости.
А вот на этапе производства (типа на TSMC) закладки вставить нельзя, так как микросхему можно просто вскрыть и проверить соотвествие GDSII файла, который проектировщик посылал на фабрику - готовой микросхеме.
Прелесть искусственных языков в том, что их грамматики логичны и хорошо проработаны, но не стоит забывать, что лингвистика - дескриптивная наука, она описывает закономерности в том, что уже есть.
Эсперанто здесь характерный пример: изначально были 16 правил, которые описывали грамматику не исчёрпывающе, что дало возможность языку стартовать. После более чем 100 лет его развития, он на мой взгляд, уже стал живым, имеет литературный стандарт: PMEG (страниц 700 текста).
Он, конечно, сохранил сильную регулярность и дружелюбность к новичкам, но у него появились более высокие уровни владения языком, которых достичь так же трудно, как и для других естественных языков.
Процесс проектирования и разработки вполне может быть итеративным и иерархичным: как для всего ПО, так и для его частей.
… выделять отдельный этап прототипирования, результат которого будет в дальнейшем выброшен, не всегда имеет смысл. Прототипироваванием можно заниматься по ходу разработки.
Это практически всегда вредно для достаточно большого объёма предметной области:
разработка подразумевает выполнение требований, а прототипирование — выяснение и уточнение требований, валидация соответствия решения требованиям.
Смешение этих процессов приводит к тому, что на прототип тратится слишком много сил, после чего выкинуть его не позволяет бизнес, оставляя ПО с архитектурой, не соответствующей предметной области, скоплением костылей и сомнительных решений. Т. е. возрастают накладные расходы на внесение изменений.
Ещё отдельно отмечу, что результатом прототипирования являются уточнённые требования к реализации: сущности, их отношения и интерфейсы. Этот результат, естественно, никуда не выбрасывается.
Проектирование, если брать его целиком, одним из первых этапов включает этап прототипирования, когда создаётся прототип, предназначенный для определения верности (валидности) подхода, определения сущностей и отношений между ними, чернового определения границ и точек споряжения.
После прохождения этого этапа уже можно проектировать целевой продукт с учётом известных особенностей предметной области. На этом этапе закрытие реализаций интерфейсом необходимо, так позволяет уменьшить когнитивную нагрузку, распределить силы команды по реализации, вовремя понять, что разбиение по сущностям неверно: при конкретных реализациях невыявленные требования часто протекают между частями и потом потом предоставляют кучу боли.
Этапы анализа и прототипирования часто опускают, если предметная область понятна и есть опыт реализации.
Я так понимаю, что вы опытным путём вышли на необходимость прототипирования и попытались донести эту мысль.
Насколько мне известно про обучение детей языку, одним из существенных факторов является непосредственная обратная связь, которую им дают родители и прочие носители языка.
Т. е. ребёнок что-то сказал или спросил и его сразу поправляют, и это где-то до 5-8 лет (не помню уже точно), после чего поправлять уже сложнее, у ребёнка уже сложилось своё представление о языке и он может уже оспаривать коррекции.
Просто экспозиция языка ребёнку особого эффекта на изучение языка не даёт, кроме фонетики.
Не у всех взрослых людей есть такой доступ к носителю языка, который готов постоянно его поправлять как ребёнка.
некоторые вообще считают, что синглтон в программе должен быть один.
У меня жена из-за похожих сбоев перестала быть родственницей своей матери.
Похоже, что данные с со случайной вставкой загружаются в сдвиговый регистр и там раз двадцать прокручиваются.
Разные полиномы дают разные характеристики обнаружения ошибок.
Т. е. полином 0xf8c9140a, который обнаруживает 8 ошибок на данных до 992 бит, обнаружит и меньшее количество ошибок, но вот полином 0xad0424f3, обнаруживающий три ошибки на данных до 4294967263 бит, может и не заметить 8 ошибок.
Также полином 0xf8c9140a, который обнаруживает 8 ошибок на данных до 992 бит, на большем кодовом слове действительно может не обнаружить ошибок вообще.
А что подразумевается под шифрованием полиномом?
Проблема английского как раз в том, что это далеко не легковесный язык. А Эсперанто приспособился к тому, что миру такой общий язык общения не нужен и просто живёт среди энтузиастов.
Можно вот эту статью, например, посмотреть: How the 8086 processor's microcode engine works.
У Эсперанто немного другая задача: это легковесный fallback-язык, который не заменяет родные языки, а позволяет общаться, когда у собеседников нет совпадения по родным языкам.
И это печально, что такой более совершенный метод не используется.
C таймаутами возникает проблема по полной утилизации линии, а с преамбулами, как я писал выше, встречал странные алгоритмы восстановления синхронизации.
Обработка ошибок это уже не канальный уровень. А работать с кадрами, для которых уже определена граница и целостность (при адекватной длине и CRC), гораздо удобней.
Сравнивал я с определением границ кадра по преамбуле, с определением границы по таймауту, с использованием длины данных в заголовке.
Эти все варианты зачастую порождают сложные эмпирические алгоритмы по восстановлению/синхронизации, теряют корректные кадры, если предыдущие потеряли символ.
Контролируемая избыточность это сильный аргумент: простые алгоритмы байт-стаффинга могут привести к удвоению размера всего кадра, а это и лишняя память под буферизацию, искажение временных характеристик -- это не дело, когда в зависимости от содержимого кадры передаются за разное время. В COBS, например, максимальные затраты это 1 байт на 254 байта исходного кадра.
Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
На мой взгляд использовать байт-стаффинг для канального уровня гораздо лучше, чем альтернативы: не надо знать заранее размер передаваемых данных; границы пакета всегда чётко определены; если использовать COBS, избыточность контролируема; подходит под любые скорости.
Можно эту статью, например, почитать: Ulrich Drepper — What Every Programmer Should Know About Memory.
Она старая, но хороший старт в этих вопросах.
Исследователи из Мичигана такое воплотили: This 'Demonically Clever' Backdoor Hides In a Tiny Slice of a Computer Chip.
Я на работое пользуюсь комбинацией cmd + ps: cmd устанавливает разрешение и потом запускает собственно скрипт.
Эсперанто здесь характерный пример: изначально были 16 правил, которые описывали грамматику не исчёрпывающе, что дало возможность языку стартовать. После более чем 100 лет его развития, он на мой взгляд, уже стал живым, имеет литературный стандарт: PMEG (страниц 700 текста).
Он, конечно, сохранил сильную регулярность и дружелюбность к новичкам, но у него появились более высокие уровни владения языком, которых достичь так же трудно, как и для других естественных языков.
Очень напоминает [Deficit Weighted Round Robin](https://en.wikipedia.org/wiki/Deficit_round_robin), только на вход.
Процесс проектирования и разработки вполне может быть итеративным и иерархичным: как для всего ПО, так и для его частей.
Это практически всегда вредно для достаточно большого объёма предметной области:
разработка подразумевает выполнение требований, а прототипирование — выяснение и уточнение требований, валидация соответствия решения требованиям.
Смешение этих процессов приводит к тому, что на прототип тратится слишком много сил, после чего выкинуть его не позволяет бизнес, оставляя ПО с архитектурой, не соответствующей предметной области, скоплением костылей и сомнительных решений. Т. е. возрастают накладные расходы на внесение изменений.
Ещё отдельно отмечу, что результатом прототипирования являются уточнённые требования к реализации: сущности, их отношения и интерфейсы. Этот результат, естественно, никуда не выбрасывается.
Проектирование, если брать его целиком, одним из первых этапов включает этап прототипирования, когда создаётся прототип, предназначенный для определения верности (валидности) подхода, определения сущностей и отношений между ними, чернового определения границ и точек споряжения.
После прохождения этого этапа уже можно проектировать целевой продукт с учётом известных особенностей предметной области. На этом этапе закрытие реализаций интерфейсом необходимо, так позволяет уменьшить когнитивную нагрузку, распределить силы команды по реализации, вовремя понять, что разбиение по сущностям неверно: при конкретных реализациях невыявленные требования часто протекают между частями и потом потом предоставляют кучу боли.
Этапы анализа и прототипирования часто опускают, если предметная область понятна и есть опыт реализации.
Я так понимаю, что вы опытным путём вышли на необходимость прототипирования и попытались донести эту мысль.
Насколько мне известно про обучение детей языку, одним из существенных факторов является непосредственная обратная связь, которую им дают родители и прочие носители языка.
Т. е. ребёнок что-то сказал или спросил и его сразу поправляют, и это где-то до 5-8 лет (не помню уже точно), после чего поправлять уже сложнее, у ребёнка уже сложилось своё представление о языке и он может уже оспаривать коррекции.
Просто экспозиция языка ребёнку особого эффекта на изучение языка не даёт, кроме фонетики.
Не у всех взрослых людей есть такой доступ к носителю языка, который готов постоянно его поправлять как ребёнка.