Не верю, что эта задача нерешаема

crypto
Вы исходите из того, что задача нерешаема
Обратите внимание, в какой форме я представил 900

 

Больше 50000h, 50000 или 050000 ? =)

0000000011.10000100 = 01604
10000100.00000000.11000000.00000000.00000000 - пакет без сигнатуры

00000101.10000001.00000000.01100000.00000000.00001001.00000000.00000101.00000000.0000 0011.00000000.00000000

00000101.10000001.00000000.01100001.00000000.00001001.00000000.00000101.00000000.0000 0011.00000000.00000000

по идеи у нас есть ещё один известный параметр, ибо мы можем обойти все ?50000? свичей и установить точно номера сгоревших и как они расположены =)

 

Что было у меня в кармане:
const "MS";
f(
word NumOfSwitch;
word NumOfLive;
word LiveSwitchNumbers[];
)
f - каждый восьмой бит каждого байта является контрольной суммой байта.
Вот и вся хитрость.

 

Ваша структура не подходит:

В первом примере 3 и 5 свичи не работают, а у вас это наоборот список живых свичей. И куда делся в таком случе свич под номером 9? В пакете он есть, а в выводе его нет.

Во втором примере размер пакета 5 байт - пакет битый - не хватает заключительного 00 (как это было в первом примере - ДВА заключительных байта 00)

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

 

Посмотрите еще раз, что такое f

 

Okay.
Смотрим еще раз:
4D 53 84 00 C0 00 00
4D 53 - const "MS";
f{
84 00 - word NumOfSwitch; - ну допустим это число свитчей
C0 00 - word NumOfLive; - это как мне кажется число живых свитчей
00 - word LiveSwitchNumbers[]; - массив с номерами живых свитчей, правда не хватает нулика? =)))
}
И где тут 900 свитчей? Если число живых у нас C0h (1100 0000b), не учитывая 8й байт получаем 40h (100 0000b), то есть живых свитчей у нас 64? странно это число не куда не укладывается т.к. по примеру живых свитчей вообще не осталось.
84 (1000 0100b) - без 8-го байта это 4h (100b), то есть число свитчей тоже не относится к заданию.

P.S. 100% автор намутил с примерами, иначе бы уже давно разгадали.

 

Господа, это wasm?
84 00 C0 00 00
10000100 00000000 11000000 00000000 00000000
Жирные циферки выбрасываем, оставшиеся группируем по 8 бит:

Код (Text):

1. 10000100 00000011 00000000 00000000
2. 84           03          00           00

word [] = {384h, 0h}. Первое число — число свичей всего, второе — число живых. За ним "следует" последовательность длиной 0 живых свичей.

 

Sharp

Может быть все-таки "каждый первый бит"? Нумерация битов на письме идет справа налево. Именно эта твоя ошибка и привела im1111 выше к неправильному результату.

 

ДА!
Открой MASM/NASM/TASM набери там:
mov eax, 84h
and eax, 7Fh
И глянь чему будет равно там eax.

P.S. Какой-то китайский способ счисления у вас. Можно взглянуть на код обработки этих самых чисел? =)
P.S.2. Не ну "Жирные циферки выбрасываем, оставшиеся группируем по 8 бит:" я под столом!!!. Зачем? Вы представляете себе как это выглядит на asm? Ну ладно просто сдвинуть байт на 1 бит через shl в данном случае вполне быстро и логично, но чтобы байты ломать "выбрасывая" биты и группируя их заново! это что-то новое

 

Sharp
кг/ам
аффтар тешит свое самолюбие этой задачей. И не более.

 

В моем коде обработки (и генерации примеров) битовые последовательности обрабатываются как строки, и их элементы нумеруются как элементы строки — слева направо. Если вы увидели здесь неоднозначность, достаточно было выписать аргумент f и ее результат, и она тут же разрешилась бы.
Это что-то новое, в частности, используется в сжатии Хаффмана. Байты там тоже составляются из отдельных последовательностей бит, причем, о, ужас, вообще говоря, разной длины.

 

В сжатии проверочные биты никогда не используются. Вы наверно путаете с кодами Хемминга. + Коды исправляющие ошибки используются обычно на нижних уровнях сетевого стэка, поэтому никто их на уровне протокола приложения (тем более битовых кодов) ожидать не будет.

 

halyavin
Правильно подметил.

Ну даже если бы он там использовался, то зачем он нужен в протоколе? В сжатии цель - увеличить компрессию любыми средствами, а проверку контрольной суммы обычно делают простой и понятной.
Ваша проверка:
Для провреки необходимо сосчитать биты каждого байта (о ужас!) + сломать байты и сгруппировать их заново (еще ужаснее).
Обычная проверка:
Посчитать с применением сложения и битовых сдвигов контрольную сумму всех байтов пакета, при этом байты не страдают. В итоге все красиво и понятно.
Почти во всех протоколах для проверки контрольной суммы используется дополнительный байтик в пакете, ну пускай 8й битик. Вопрос что нам дает "физическое" удаление 1го или 8го бита? - Это бессмысленно! не несет никакой пользы, лишь затраты ресурсов и вот такие траблы с пониманием пакетов. Скажите честно вы кодите на Delphi?

 

Фигня, я в 10 раз замутнее могу придумать. Так, что сам потом не пойму как это работает

 

halyavin, я привел Хаффмана исключительно в качестве первого примера, где байты нужно "разрезать" и/или "склеивать". Еще можно вспомнить BASE64, XXEncode и много других страшных слов.
Нигде не сказано, что это протокол уровня приложения.
Задача придумать простой, а тем более понятный протокол, не стояла, т.к. участники должны были показать умение решать сложные, а не банальные проблемы. Кроме того, учитывая, что порой в реальных протоколах встречается, скажем, передача точного объема трафика, используя тип float (!), этот протокол — просто верх логичности, особенно, учитывая, какие сети у компании "Гидронет" Конечно, если бы задача была в 10 раз замутнее, примеров было бы в 10 раз больше. На Delphi я не пишу.

 

)))))))
Вы не ответили на вопрос для чего используется "физическое" удаление битов, в чем логика?

 

Что вас смущает в использовании 7 бит данных на байт?

 

Ничего.
Мне хочется узнать в чем смысл "физического" вырезания битов.

 

Это обратная к составлению байт указанного строения операция.

 

Оставим биты в покое...

Мое личное мнение, что при проектировании таких задач, все-таки следует придерживаться сегодняшних реалий и здравого смысла.

Ваша задача - передача одного пакета информации. Сегодняшние локальные сети накладывают жесткое ограничение на размер передаваемой информации в одном пакете. Поэтому при разработке структуры самое главное правило - размер структуры должен быть минимальным. Ваше решение использования одного бита в байте:
во-первых - разбухание пакета
во-вторых - программное дублирование физической передачи данных (так как, например по компорту данные тоже передаются с таким битом (он там называется бит четности)
в-третьих - слабый контроль ошибок (бит четности\нечетности - примитивная защита -более эффективно - контрольная сумма блока)
Так-же современные системы передачи данных гарантируют (не на 100% ), что принятый пакет - правильный. Это реализуется в виде расчета контрольной суммы при передаче, и ее контроля при приеме. Поэтому дополнительно поле, для общей контрольной суммы является опять программным дублированием, да еще и потерей размера пакета.

Итог - Ваша зада является идеальным примером, КАК НЕ НУЖНО ПРОЕКТИРОВАТЬ. Все, кто здесь пытался решать, все-таки исходили из ситуации описанной Вами (Микрософт, ла-ла-ла....) и из здравого смысла. Так что, действттельно, ТАКАЯ задача не может быть решена.