Байто-битовые сношения

[CuteBunny]

Привет, Всем!

Можно ли упаковать от 2 до n байтов в один байт, а потом их извлечь из этого байта?

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

[ammaximus]

Ну, если известно что значимые биты всегда в начале байта, то можно упаковать n байт в один, где n= ceil (8 div макс кол-во значимых байт).
Не знаю, где это может пригодится, если в канале большая нагрузка лучше заняться оптимизацией протоколов обмена, как я в соседней теме.

[Bepec]

Упаковать и восстановить можно, но необходима будет дополнительная информация о неиспользуемых битах.
Вот тут уже вопрос, не будет ли это избыточно.

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

[CuteBunny]

Ок, попробуем: допустим 2 байта на входе, в первом 2 бита используются,
в другом 3, максимальное кол-во битов 3, считаем n = ceil(8/3) => n = 2, хорошо, а дальше как паковать в байт, чтоб потом можно было извлечь и восстановить?

В принципе цель не стоит в оптимизации передачи данных по сети, цель избежать избыточности данных. Хотя, если такой вариант в принципе "не стоит выделки", тогда ладно, забили.

[CuteBunny]

Упаковать и восстановить можно, но необходима будет дополнительная информация о неиспользуемых битах.
Вот тут уже вопрос, не будет ли это избыточно.

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

Короче не стоит оно того?

[ammaximus]

1. Не должно быть ранней оптимизации
2. Не должно быть оптимизации того, что и так работает
Это еще от макконела помню)

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

а дальше как паковать в байт

Ну так тут довольно просто, делим байт пополам - левая половина первый байт правая второй. Но как и сказал Верес, придется при изменении n каждый раз посылать служебное сообщение с предупреждением.

В оптимизации часто бывает, что кажется улучшаешь, на самом деле сделал хуже. Для этого нужно собирать статистику, проводить испытания. Это отдельная работа, она часто оказывается сложнее, чем основная.

[CuteBunny]

1. Не должно быть ранней оптимизации
2. Не должно быть оптимизации того, что и так работает
Это еще от макконела помню)

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

а дальше как паковать в байт

Ну так тут довольно просто, делим байт пополам - левая половина первый байт правая второй. Но как и сказал Верес, придется при изменении n каждый раз посылать служебное сообщение с предупреждением.

В оптимизации часто бывает, что кажется улучшаешь, на самом деле сделал хуже. Для этого нужно собирать статистику, проводить испытания. Это отдельная работа, она часто оказывается сложнее, чем основная.

Ок, спасибо.

[Bepec]

На данный момент проблемы с пропускным каналом в сети присутствуют только у специализированных устройств, поток информации от которых больше пропускной способности сети.

Ну и если проще выразиться - на каждый "сэкономленный" байт вам придётся слать сервисное сообщение из 2 байт. И так далее и тому подобное.

Задача что вы предложили чрезвычайно сложна - самый известный её "шуточный" вариант - восстановление фильма из md5 .

PS Не стоит экономить байты. Нужно экономить мегабайты