Это многое объясняет, да.
Уже то, что ты работаешь с символами ( не важно, utf это или что - то ещё ) - уже сразу отбрасывает тебя назад по сравнению с бинарным представлением.
То есть ты ещё не начал ничего сжимать - а уже 12% объема к данным добавил.
Не говоря уже о том, что такой подход делает абсолютно бессмысленными другие твои предложения. Например вот тут изложена полная чушь:
Вместо кодирования точки одним битом, ты предлагаешь тратить два байта - в 16 раз больше. Какое же это сжатие?
Если хочешь что-то говорить о сжатии, сначала научись работать с битами.
ЗЫ
Это замечание по тактике.
Стратегически твоя затея полная белиберда и возникла исключительно по причине того, что ты не знаком с фундаментальными законами физики 
если вы не про стиль написания, то перед загрузкой кода через ардуино надо нажать сохранить скетч, и это помогает избежать крякозябр в мониторе порта… кодировка переключается с 1251… но могу и ошибаться…
это что бы показать как… нечего не мешает вовсе опять же применить алгоритм Хаффмана и сжать данные… например каждые 8 байтов 00000000 передать как 01… для понимания написал так… а то будет запутанно…
все нет времени флудить))))
Стиль? Так гуманитарии на первом курсе программы пишут.
Но я же не профессор, просто спросил.)
Смешно рассуждать о сжатии, оперируя текстовым представлением чисел.
Это как рассуждать о победе в автогонке, первым делом затянув ручник.
Смотришься полным идиотом, поверь.
Отчего же?
Скорее - наоборот. С текстовыми данными есть хоть какая-то гарантия сжатия, чего в бинарных данных не наблюдается.
Давайте-ка я вам на вентилятор накину, на правах старого тролля.
Смотрите: можно рассматривать блоки бит ( достаточно длинные) как большие числа.
По основной теореме математики, каждое составное число представимо в виде произведения простых.
Простые числа можно вычислить заранее и присвоить им индексы.
Операция кодирования будет раскладывать числа на простые сомножители и выдавать уже индексы простых чисел.
Пример:
Простые числа: 2,3,5,7. 2 бита потребуется, чтобы хранить порядковый номер простого числа.
Число 49, можно разложить как 7*7, т.е. в 4 бита.
Открываются невиданные доселе горизонты.
не до вечера потерплю))
49 (6 бит) можно разложить в 7 х7 и записать как 2 + 2 бита - экономия!
50 (те же 6бит) = раскладываем как 2х5х5 = 2+2+2 бит, экономии нет
51… не раскладывается… упс
2 лайка
А 2+2 - это 4. Влезает в три бита! Сжатие - 50%.
1 лайк
а 2-2? ))
1 лайк
20769187434139310514025424420847616 при делении на 2 пока что не получится 1
показывает эффективность 2076918743413931051402542442084761% еще можно использовать например другую систему счисления, после 8192 ставить 1 перед 8192 а 8192 стирать)))) токо это не работает)))) ну по крайней мере начали что то предлагать))))
тоесть с 34359738368000134217728000000524288 эффективность 34359738368000134217728000000524287% … слушайте а тут те кто с правами случайно не могут чужие сообщения подправлять без палева, так же как и темы ?))))
А это читерство.
1 лайк
Во-первых, не для вас был наброс.
А во вторых, 51 - это само по себе простое число, конечно не разложится
а на 3 и 17 оно больше не делится штоли? Какой-то указ был, а я не знаю?
1 лайк
…
ардуино форум: существует
…
Бабос заявляет о начале разработки супер сжатия без ограничений
…
…
попытка опровергнуть основную теорему арифметики
ВЫ НАХОДИТЕСЬ ЗДЕСЬ
перспективы оцените сами
1 лайк
А, чорт. :-E
Ну так это еще Обама…
1 лайк
Ладно, это всё фигня. Математики есть?
Из наболевшего:
Есть массив, ну , скажем, 2 тыщщи указателей.
Ну или лучше - 2 тыщщи каких то абстрактных 32-битовых чисел.
Все - уникальные.
Хочется:
Найти несложную функцию f() такую, что если натравить ее на вышеуказанные числа, то она выдаст их порядковый номер в массиве.
Пример:
Мaссив: [1 , 32768, 99, 400000, 13]
Функция: f(1)=0, f(32768)=1, f(99)=2, f(400000)=3, f(13)=4.
Т.е. сжимающее отображение.
Примеров сжимающих отображений много, например - CRC16. Но у нее выход непредсказуемый, про него лишь известно, что 16 бит :).
А хочется, как в примере выше.