Что значит зачем, для сжатия же. Например, если делать Variable-Length Integer на 7-битном алфавите, пусть старший (6-й) будет как бит продолжения. Тогда в двух символах можно закодировать число до 2047, тогда как в десятичном это аж 4 символа.
Нет, он делался для задачи получения одинаковых хэшей от семантически одинакового содержимого. Минимизация там не ставилась (что и видно по десятичным числам).
Только ASN.1, и этот ужас давно пора закопать. Там вариации парсеров уже на OID начинаются, не говоря уже обо всём остальном, что ведёт к бесконечной череде дыр в реализациях до сих пор...
реализовал на сервере справочник ключей, который для каждой предметной области, определяемой типом сообщения, хранится на сервере и перед отправкой заменяется в JSON, например temperature - t
Хардкод вместо расширяемых словарей? Весело...
чуть более компактный YAML
В YAML из хорошего только модель данных (например, тип как строка, в CBOR вместо этого числовые теги, что неудобно), остальное лучше делать иначе...
Это крайне забавно. Я участвую в CBOR WG в IETF, причем как раз по вопросам дальнейшего сжатия (и так более компактного нежели JSON формата) - имелся как свой у них draft-cbor-packed с фокусом на распаковке constrained IoT-нодой без промежуточного буфера (там всё плохо с памятью как на данные, так и на код); так и я со своим CBAR, делавшимся из других вводных - он делался для транспортного (L4/L5, как TCP или QUIC) протокола muSCTP, предназначенного выживать на пакетах минимум 24 байта (в общем-то пересекается с озвученными в статье областями применения); базовая идея у обоих в общем-то одна - сжать повторяющиеся ключи. Сначала я пробовал на нибблах и секстетах свой формат слепить, потом решил, что на типичном куске 9 vs 10 байт (или 10 vs 11, уж не помню) выгода от экономии не перевешивает сложности имплементации, тестов и т.д. нового формата: куда лучше сделать специфический компрессор для common формата (т.е. приложения смогут пользоваться расширенной моделью данных JSON), а пару лет назад мне еще подсказали компактную либу (Compress::LZF), в смысле добавить два уровня (две фазы) паковки. Идут баталии в мэйллисте насчет недостатков cbor-packed, появляются новые идеи по хитростям увеличения компрессии на базе примера DNS-CBOR (да, в процессе драфт и такого RFC)...
И тут появляется какой-то пижон Сиджон, начисто игнорирует годы рисёрча людей, и заявляет - а давайте делать это ТЕКСТОМ, более того, в base64! BASE64, Карл!!! Я аж подавился и пролистал в начало статьи - это точно не первое апреля?!.. При этом в постановке задачи кроме очерчивания области нет толком вообще ничего, альтернативные форматы упомянуты - но самого сравнения-то нет! (а CBOR, между прочим, четко сформулировал иерархию целей и на каждый сравниваемый формат, в т.ч. MessagePack, который был ближе всего, потратил несколько абзацев, почему это не подходит).
Более того, в постановке задачи даже АЛФАВИТА нет! Из упоминания DTMF (что? он же явно не первичен как определяющий, а будет ниже слоем рекодинга, смысл-то) и SMS можно догадаться, что предполагается не 8-битный канал. Но валидный набор символов не озвучен (я вспоминаю одну странную штуку с алфавитом на 45, из QR-кодов штоль). Можно предположить, однако, что прекрасно подойдёт как минимум base85, а возможно что и наработки времён Fido по произвольным чарсетам (не помню как звали, creeper что ли). Наконец, снова смотреть на возможности канала - мне что-то попадалось насчет кодировки типа baseN, рассчитанной на UTF-8 строку (аналогично можно для неполного UCS-2 придумать). Далее, человекочитаемым ему быть совершенно незачем, это тоже вредит сжатию. Ему нужно быть лишь человекоотлаживаемым (например, подбором удобных значения для hexdump'ов), а это другое. Нет, способность к восстановлению при повреждениях необязательно требует текстовости формата, её можно вполне обеспечить в бинарном (кстати, в полном 7-битном репертуаре там еще символы 0-31 есть, на минуточку) - это свойство даже у UTF-8 есть (хоть и на уровне отдельных символов, а не более объемлющего структурного формата).
В общем, уровня поиграться "смотрите как я пиарюсь очередным велосипедом" - может быть. В качестве серьезного формата - точно нет, не надо этому CJON засорять инфопространство - лучше направлять усилия туда, где люди уже занимаются проблемой.
следует из их системы аксиом, в которой они и делают ключевую ошибку (воспринимают существование как некоторую предметность, а не как свойство - и движение оказывается невозможным, потому что всё вокруг оказывается заполнено субстанцией-носителем существования).
Но коим боком? В самой апории, что про черепах, что про стрелу - этого нет. И без этого "работает", в т.ч. разбивание на бесконечное число частей.
Полного? Конечно нет, не влезет, ведь в них же меньше гигабайт, чем в новом. А то, что проектируется, оно по частям делается - например, только процессор, без всех транзисторов оперативы. И части эти склеивает человек, не машина.
Что ж тут неочевидного? Мерять влезание, т.е. объем информации литрами - это либо очень толстый троллинг, либо не будем говорить то, что может привлечь модераторов.
То есть проектировщику не надо держать в голове всю систему до мельчайших подробностей?
Речь шла об энергосистеме. Там математические модели её здорово упрощают по сравнению с реальными устройствами. Но попытка применить аналогичный подход к транзисторам в процессоре, почему-то, потерпит провал :)
Абсолютно всю систему? Вплоть до схемы каждого отдельного компьютера, которые к этой системе подключены? Серьёзно? Или в каждый отдельно взятый момент времени у него в голове может находиться только какая-то небольшая часть системы?
Сказано же - "может". И дальше же сказано - "из-за объема работы". Проще говоря, берете условного одного программиста Леголаса, и он за 150 лет в своем Лориэне один накодит то же самое, что контора за год. Значит, они эквивалентны. Вот если бы контора смогла за 10 лет сделать нечто такое, на что Леголас не способен за всю Третью Эпоху, вот тогда можно было бы говорить, что "коллективный разум" превышает возможностями одиночный. Но это требует доказательств, потому что опыт с толпой говорит скорее об ухудшении коллективных качеств.
Не в "схему" телевизора, а в него самого. Точнее, делаете вычислительную машину на эквивалентном телевизоре числе ламп (и прочих элементов) и смотрите, сколько в неё помещается.
Вот-вот, не разбираются детально, а потом думают, что этого достаточно. Именно потому критика перцептронов и была разгромной в книге 70-го года, после чего все резко переключились на другие направления исследований - в наше время просто решили залить вычислительными мощностями. Да, как и всегда в бионике, даже некоторое подобие подсмотренного у природы принципа дает значительный прогресс. Но фундаментальные-то ограничения не сняты - вот и в этот раз пузырь нейронок сдуется.
Логическая работа нейрона - крайне простая. У него есть куча аксонов (входов) и 1 дендрит( выход). По аксонам поступают электрические импульсы в виде ШИМ модуляции от других нейронов. Исходя из внутренней настройки нейрона (какие то аксоны тормозящие, какие то нет) - в определённый момент (когда по входящим аксоном придёт достаточное количество ШИМ сигнала) он срабатывает и начинает выдавать такой же ШИМ сигнал в свой выход
Сразу нет. Это описание используемой условной модели нейрона, применямых в нейросетках, а не реального биологического. Там не электричество, это раз. И не ШИМ, это два. И по одному аксону передаются сразу десятки сигналов (аналоговых, ага), это три.
Но клеточная биохимия рассчитана только на жизне-поддержание конкретного нейрона, в целом на алгоритм работы мозга она не влияет. Ну может при шизофрении - или при принятии наркотиков, когда нейрон начинает срабатывать не по алгоритму аксоном, а рандомно.
Соответственно, тоже неверно. Нет там "алгоритма", есть разные уровни аналоговых сигналов. И шизофрения/наркота отличается только количественно, а не качественно - проще говоря, в условно "нормальном" состоянии работа тоже отличается. Так что не "биохимия рассчитана", именно она и является определяющей для работы.
Поэтому оно и обречено на провал - достаточно спросить нейрофизиологов типа того же профессора С.В.Савельева.
Что значит зачем, для сжатия же. Например, если делать Variable-Length Integer на 7-битном алфавите, пусть старший (6-й) будет как бит продолжения. Тогда в двух символах можно закодировать число до 2047, тогда как в десятичном это аж 4 символа.
Нет, он делался для задачи получения одинаковых хэшей от семантически одинакового содержимого. Минимизация там не ставилась (что и видно по десятичным числам).
Только ASN.1, и этот ужас давно пора закопать. Там вариации парсеров уже на OID начинаются, не говоря уже обо всём остальном, что ведёт к бесконечной череде дыр в реализациях до сих пор...
Хардкод вместо расширяемых словарей? Весело...
В YAML из хорошего только модель данных (например, тип как строка, в CBOR вместо этого числовые теги, что неудобно), остальное лучше делать иначе...
А кто этот формат из полученной SMS декодировать будет? Всё-таки машина? Ну а смысл тогда...
Это крайне забавно. Я участвую в CBOR WG в IETF, причем как раз по вопросам дальнейшего сжатия (и так более компактного нежели JSON формата) - имелся как свой у них draft-cbor-packed с фокусом на распаковке constrained IoT-нодой без промежуточного буфера (там всё плохо с памятью как на данные, так и на код); так и я со своим CBAR, делавшимся из других вводных - он делался для транспортного (L4/L5, как TCP или QUIC) протокола muSCTP, предназначенного выживать на пакетах минимум 24 байта (в общем-то пересекается с озвученными в статье областями применения); базовая идея у обоих в общем-то одна - сжать повторяющиеся ключи. Сначала я пробовал на нибблах и секстетах свой формат слепить, потом решил, что на типичном куске 9 vs 10 байт (или 10 vs 11, уж не помню) выгода от экономии не перевешивает сложности имплементации, тестов и т.д. нового формата: куда лучше сделать специфический компрессор для common формата (т.е. приложения смогут пользоваться расширенной моделью данных JSON), а пару лет назад мне еще подсказали компактную либу (Compress::LZF), в смысле добавить два уровня (две фазы) паковки. Идут баталии в мэйллисте насчет недостатков cbor-packed, появляются новые идеи по хитростям увеличения компрессии на базе примера DNS-CBOR (да, в процессе драфт и такого RFC)...
И тут появляется какой-то
пижонСиджон, начисто игнорирует годы рисёрча людей, и заявляет - а давайте делать это ТЕКСТОМ, более того, в base64! BASE64, Карл!!! Я аж подавился и пролистал в начало статьи - это точно не первое апреля?!.. При этом в постановке задачи кроме очерчивания области нет толком вообще ничего, альтернативные форматы упомянуты - но самого сравнения-то нет! (а CBOR, между прочим, четко сформулировал иерархию целей и на каждый сравниваемый формат, в т.ч. MessagePack, который был ближе всего, потратил несколько абзацев, почему это не подходит).Более того, в постановке задачи даже АЛФАВИТА нет! Из упоминания DTMF (что? он же явно не первичен как определяющий, а будет ниже слоем рекодинга, смысл-то) и SMS можно догадаться, что предполагается не 8-битный канал. Но валидный набор символов не озвучен (я вспоминаю одну странную штуку с алфавитом на 45, из QR-кодов штоль). Можно предположить, однако, что прекрасно подойдёт как минимум base85, а возможно что и наработки времён Fido по произвольным чарсетам (не помню как звали, creeper что ли). Наконец, снова смотреть на возможности канала - мне что-то попадалось насчет кодировки типа baseN, рассчитанной на UTF-8 строку (аналогично можно для неполного UCS-2 придумать).
Далее, человекочитаемым ему быть совершенно незачем, это тоже вредит сжатию. Ему нужно быть лишь человекоотлаживаемым (например, подбором удобных значения для hexdump'ов), а это другое. Нет, способность к восстановлению при повреждениях необязательно требует текстовости формата, её можно вполне обеспечить в бинарном (кстати, в полном 7-битном репертуаре там еще символы 0-31 есть, на минуточку) - это свойство даже у UTF-8 есть (хоть и на уровне отдельных символов, а не более объемлющего структурного формата).
В общем, уровня поиграться "смотрите как я пиарюсь очередным велосипедом" - может быть. В качестве серьезного формата - точно нет, не надо этому CJON засорять инфопространство - лучше направлять усилия туда, где люди уже занимаются проблемой.
Лучший? Вот уж не надо тут. Один из худших.
А теперь с CBOR сравните, и тоже со сжатием...
Но коим боком? В самой апории, что про черепах, что про стрелу - этого нет. И без этого "работает", в т.ч. разбивание на бесконечное число частей.
Описанное - не самообучение. Это скорее "отправить на курсы повышения квалификации", на которых "всё разжуют", и то аналогия кривая.
Для самообучения он должен сам, непрерывно, онлайн себя изменять-обучать - как любое биологическое существо с достаточно сложным мозговм.
Полного? Конечно нет, не влезет, ведь в них же меньше гигабайт, чем в новом. А то, что проектируется, оно по частям делается - например, только процессор, без всех транзисторов оперативы. И части эти склеивает человек, не машина.
Что ж тут неочевидного? Мерять влезание, т.е. объем информации литрами - это либо очень толстый троллинг, либо не будем говорить то, что может привлечь модераторов.
Речь шла об энергосистеме. Там математические модели её здорово упрощают по сравнению с реальными устройствами. Но попытка применить аналогичный подход к транзисторам в процессоре, почему-то, потерпит провал :)
Сказано же - "может". И дальше же сказано - "из-за объема работы". Проще говоря, берете условного одного программиста Леголаса, и он за 150 лет в своем Лориэне один накодит то же самое, что контора за год. Значит, они эквивалентны. Вот если бы контора смогла за 10 лет сделать нечто такое, на что Леголас не способен за всю Третью Эпоху, вот тогда можно было бы говорить, что "коллективный разум" превышает возможностями одиночный. Но это требует доказательств, потому что опыт с толпой говорит скорее об ухудшении коллективных качеств.
Не в "схему" телевизора, а в него самого. Точнее, делаете вычислительную машину на эквивалентном телевизоре числе ламп (и прочих элементов) и смотрите, сколько в неё помещается.
Ну да. Сколько у того Спектрума мегабайт было? А сколько займёт полная схема смартфона, скажем в .dwg ?
Точно, сейчас нам аноним с Хабра решит двухтысячелетнюю проблему и опровергнет свод знаний по вопросу, представленных в энциклопедии.
Как это не мешает? Построить такую модель, как у реального биологического мозга - это очень сложно и дорого. Я даже пытаться не буду.
Вот-вот, не разбираются детально, а потом думают, что этого достаточно. Именно потому критика перцептронов и была разгромной в книге 70-го года, после чего все резко переключились на другие направления исследований - в наше время просто решили залить вычислительными мощностями. Да, как и всегда в бионике, даже некоторое подобие подсмотренного у природы принципа дает значительный прогресс. Но фундаментальные-то ограничения не сняты - вот и в этот раз пузырь нейронок сдуется.
Сразу нет. Это описание используемой условной модели нейрона, применямых в нейросетках, а не реального биологического. Там не электричество, это раз. И не ШИМ, это два. И по одному аксону передаются сразу десятки сигналов (аналоговых, ага), это три.
Соответственно, тоже неверно. Нет там "алгоритма", есть разные уровни аналоговых сигналов. И шизофрения/наркота отличается только количественно, а не качественно - проще говоря, в условно "нормальном" состоянии работа тоже отличается. Так что не "биохимия рассчитана", именно она и является определяющей для работы.
Поэтому оно и обречено на провал - достаточно спросить нейрофизиологов типа того же профессора С.В.Савельева.
А что там её готовить? Газ стоит копейки, вода тоже. Электричество ж еще подороже будет - КПД-то его производства невелик.