>>62877

>Если сжатие без потерь хочешь, то по идее можно его добиться

>если работать относительно каких-нибудь генераторных схем с особо сложным устройством.

Именно.
Изначально, я себе в голове, вообще рисовал некое устройство, алгоритм, функцию, то есть - некий порождатель инфы,
а именно - порождатель любого натурального числа (большой длины).

Что-то вроде вот этих чисел: https://ru.wikipedia.org/wiki/Большие_числа
В частности, какая-то такая вот функция:

>1928 год — Вильгельм Аккерман опубликовал свою функцию.

То есть, некая функция, которая принимает короткие (битовая длина) параметры,
множит их, возводит в степень там, вычисляет факториалы, и прочие нотации Кнута,
и выдаёт конкретное уникальное, но - натуральное число, из всего множества натуральных N.
И, как я понял, все эти "большие числа" - могут иметь только "определённый вид",
как впрочем и "простые числа", которые с "короткой записью", на "primeGrid".
Поэтому, выдать произвольное натуральное число, размером в сектор (512 байт, например) - такие функции-алгоритмы не могут.

"Сжатие без потерь" - подразумевает кодирование повторяющихся последовательностей,
и предварительную пре-обработку,
то есть, обратимое снижение информационной энтропии "произвольных входных данных",
какую-то "обратимую оптимизацию" этих данных (как это делает всё то же - Преобразование Барроуза-Уилера),

Однако, по Шеннону, энтропия - это и есть сама информация,
и если её снизить - то надо просто выкинуть кусок инфы (реализуя сжатие с потерями),
и выкинов это говно - снизить колгоморовскую сложность этих данных: https://ru.wikipedia.org/wiki/Колмогоровская_сложность

Здесь, http://kodpi.net/13/13.htm , я нашёл некий пример "сжатия - несжимаемых данных",
они просто "выкинули байт", а потом "подобрали его", хэххэх.
Можно было бы "выкинуть" и "много байт", а потом - "подобрать их".
Такой многораундовый алгоритм я тоже искал - чтобы с помощью него, можно было бы,
вычислительные мощности приложить, порождая из короткой инфы, более громоздкую, но однозначную.

>Смысл оно будет иметь только для объёмных штук, к примеру от 1Мб, а иначе получим твои же 256->256+ вместо сжатия.

256 последовательных байт - это просто был пример "несжимаемых данных"
(то есть данных, содержащих "все возможные комбинации" всех байт).
Конечно, в качестве "несжимаемых данных", можно взять и другие "мегабайтные комбинации",
в частности "зашифрованные данные", или "случайные данные",
то есть данные, с максимальной "информационной энтропией",
данные, в которых количества единиц/нулей, и количества блоков более длинных чем бит - (00, 01, 10, 11), (0...0, ..., 1...1)
- распределены равномерно, по всем этим данным.

>само перераспределение адресов можно самыми разными хэшами делать, и любым другим дремучим ужасом

А как обратить потом?
Хэши имеют коллизии, поэтому они считаются необратимыми односторонними функциями. В этом проблема.
Поначалу, у меня тоже была идея использовать хэши, и она была простой:
вычислить хэш, и потом, просто - несмотря на ресурсы, подобрать сами данные по нему.
Но тогда, нужно указать номер коллизии (для пропуска инвалидных коллизий, при подборе),
а с этим номером (плюс сам хэш) - размер данных уже равен битовой длине самих данных.
Просто подумай, сколько коллизий будет иметь четырехбайтная контрольная сумма восьмибайтного блока данных,
если попытаться этот блок подобрать? Да, максимальное число этих коллизий может быть представлено ещё четырьмя байтами...

Поэтому, в итоге, думается мне, что лучше было бы преобразовывать инфу вентилями,
производящими "обратимые вычисления", а именно:
https://ru.wikipedia.org/wiki/Вентиль_Тоффоли
https://ru.wikipedia.org/wiki/Вентиль_Фредкина
https://ru.wikipedia.org/wiki/CNOT
Обратимые вычисления, они не херят инфу, а просто меняют данные местами.
Тогда, можно было бы, замкнуть цикличное преобразование на много раундов, не теряя инфы, а адреса - сдвигать,
и таким образом, добиться через N-циклов - более упорядоченных данных, с меньшей энтропией,
и возможностью обратить выходные данные.

>И если данное нечто оказывается короче оригинала, то мы достигли успеха.

Но, вот-вот! Тут то и трабла.
Я рассматривал также вариант обратимой сортировки, последовательностью XOR-обменов,
но если записывать последовательность индексов элементов, где производится обмен,
то инфа (энтропия информационная), она - перемещается в них, в эти индексы,
и эта последовательность, в итоге - ещё длинее чем сама инфа.

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

Поэтому, после всего этого, хотелось бы просто составить некую таблицу глобальную,
кратчайших представлений всех натуральных чисел от 0 до 2^N (где N, скажем 64),
или, ещё лучше - так это найти формулу разложения произвольных больших натуральных чисел,
и представления их в виде более оптимальном, нежели в виде - бинарном.
Тогда, можно было бы сделать JSON-объект с таблицей замен, и пускай архиватор-деархиватор занимал бы терабайт,
но зато без проблем, жал бы гигабайты в килобайты, обратимо, и расжимал бы.

И чё-то сдаётся мне, что есть в математике - куча теорем, позволяющих представить любое натуральное число,
в виде намного более коротком, нежели в виде бинарном.

>>62709 (OP)
Как хорошо известно многим учёным,
синергетические процессы самоорганизации в кибернетических суперсистемах,
порождают негэнтропийные процессы упорядочивания информации,
снижая тем самым информационную энтропию.
В связи с этим, существуют два понятия - негэнтропия и экстропия.
https://ru.wikipedia.org/wiki/Негэнтропия
https://ru.wikipedia.org/wiki/Экстропианство

Внимание, вопрос: вывели ли уже универсальную формулу самоорганизации информации,
которая обратимо снижает информационную энтропию для произвольных входных данных,
позволяя их впоследствии - восстановить однозначно,
в результате эволюции самоорганизовавшейся системы?

Зачем спрашиваю...
Не, ну рили, как сжать без потерь - несжимаемые данные?
Там же, почти, равномерное распределение всех возможных байт!
На вид они, как рандом, информационная энтропия данных - на высоте.
В общем, надо, всю эту инфу, как-то упорядочить, но обратимо, чтобы потом восстановить.
Если просто отсортировать их (необратимо), то данные будут испорчены.

Поэтому, обращаюсь к специалистам по синергетике.
Универсальная формула самоорганизации, согла бы подарить человечеству универсальный алгоритм суперсжатия,
поскольку информацинная энтропия данных - снижалась бы, в результате синегретической самоорганизации.
Но обратимо, потому что процессы самоорганизации протекают при наличии притока энергии,
а без энергии, происходит эволюция самоорганизовавшейся системы.

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

>>62905
Ну с натуральным числом всё сравнительно просто - бинарное представление, как и любое другое - всего лишь укороченная запись полинома с плавным ростом степеней где все члены суммируются, а коэффициенты априори целые и от 0 до (основание_полинома - 1).
Даже без модификаций подобного ты можешь банально находить более удачные разложения чем в десятичной системе и получать укороченную запись (но прочтение и алгебраические операции станут усложнёнными).
Если брать гибридные системы счисления, то можно например сделать так:
[основание](коэффициент_степерь) + ...
Соответственно:
[10](3_5) + [10](1_0) = 300001
Очевидно, что таких разложений можно придумать очень много (особенно если шарить за системы счисления и спокойно конструировать маргинальные их виды), но почти все они будут более громоздкими.
Это всё вертится вокруг понятия о нормальной форме. Т.е. такому шаблону к которому можно любое число привести однозначным образом, что позволяет далее сравнивать величины. Но если сравнивать - не главная задача, то мы можем делать что угодно.
В случае записи подобными полиномами очевидно что наикратчайшая запись будет как раз-таки в 1-3 члена, что собственно ехидно отсылает нас к проблеме Гольдбаха. Но при этом и сами основания, коэффициенты и степени могут быть столь огромными, что и к ним можно будет какую сокращённую нотацию прицепить.

>снизить колгоморовскую сложность

На мой взгляд у этого определения есть ключевая беда - оно оценивает структурную сложность в вакууме, вне всякого контекста.
Если отбросить тезис про универсальность и смотреть по существу, то мы изначально окажемся в ситуации когда мы крайне огромное понятие пытаемся описать в рамках какого-то контекста.
А раз всё так, то кто мешает работать с ситуативными таблицами и прочими вспомогательными вещами? Вне полного перечисления последовательностей любую последовательность всегда легко представить в виде ситуативной ссылки в краткой форме. А как оно относится к структуре? Да весьма просто - ссылкой мы утверждаем, что поэлементные отличия последовательности от того что представлено по ссылке нулевые.
Для единичных элементов и чисел мы в целом используем ту же самую логику, поэтому игнорировать её для более крупных вещей при практических задачах - это самокастрация.

У беспредельного сжатия есть однако очевидные дикие последствия.
Во-первых, при полном перечислении совершенно точно нельзя меньшим числом записать каждое большее - коллизии будут появляться априори.
Во-вторых, если ты всё-таки находишь удачные способы краткого представления, то это порождает совершенно магическую ситуацию, когда сжатие технически ничем не ограничено. И это уже по-своему страшная ситуация, т.к. грань между 100Гб и 100Тб оказывается только во времени распаковки. И если данная схема начинает работать, то это моментально начнёт влиять на всю информационную сферу и всё что с ней связано. Если весь архив порнолаба за все года можно уместить в микрофайлик весом не больше mp3, то это чудесно.
Но точно также мы, значит, можем через стеганографию захуярить альбом Металлики в картинку с обложкой этого альбома, нисколько не увеличив размер картинки. А в каждую вложенную песню в свою очередь мы можем вложить дискографию Мегадэт. А туда ещё чего. А потом ещё. И ещё.
В итоге при передаче одной-единственной картинки может оказаться вся библиотека всех файлов мира. Но и она же самая при передаче любой другой картинки с вложенными данными.
И концептуально это таки тотальная ебатория и натуральная магия: в любом произвольном файле содержатся вообще все возможные файлы, нужно лишь иметь грамотно настроенные управляющие структуры чтобы это всё доставать.

И этого в общем-то достаточно, чтобы утверждать, что в общем случае такой алгоритм - астальная хуита.
Но вот доказать что такой подход не взлетит ни в одной частной ситуации, или даже целом классе таких ситуаций...

>>62957

>1. Ячейка памяти представляет собой фиксированное число даже не бит, а байт.

>2. Хранить биты между несколькими словами совершенно бессмысленный номер.

>3. Компьютер при побайтной работе довольно глупый - всё что он наблюдает это бесконечные байтовые последовательности.

>Без алгоритмизированного шаблона по вычленению оттуда собственно чисел, или ещё каких данных,

>хуй он тебе что сделает.

>А теперь прикить как ты твоит 4 + 5 уложишь, чтобы получилось 9 которые поймёт и считает компьютер.

Биты, то я для наглядности показал.
Если реально можно было бы так сжать, то понятно что с ростом числа, в среднем 17 байт могло бы быть сжато в 9 байт.
Ну да пофиг.

>>62956
Терь у меня немного другая идея, с этими числами Фибоначчи.
Короче, взял я последнее число Фибоначчи, и вижу:

>>> str('bitlength 2000-th Fibonacci number = ')+str(len(bin(4224696333392304878706725602341482782579852840250681098010280137314308584370130707224123599639141511088446087538909603607640194711643596029271983312598737326253555802606991585915229492453904998722256795316982874482472992263901833716778060607011615497886719879858311468870876264597369086722884023654422295243347964480139515349562972087652656069529806499841977448720155612802665404554171717881930324025204312082516817125)[2::]))+str(' bits')

'bitlength 2000-th Fibonacci number = 1388 bits'

То есть его длина 1388 бит, в бинарном виде.

Можно взять 2000 чисел, пронумеровать их индексы от 0 до 2000,
и закодировать наличие или отсутствие чисел - битами.
Например, число:
27(10) = 11011(2)
Разложу по Фибоначчи:
27 = 21 + 5 + 1

0 1 2 3 4 5 6 7 8 <- индекс числа Фибоначчи
0 1 1 2 3 5 8 13 21 <- само число
0 0 1 0 0 1 0 0 1 < - и как-то так представить число 27.
Тут уже 3 единичных бита, но длина числа в битах - 9 бит, а не 5.

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

>>63004

>А вот это очень полезное дело. Т.к. про байты отчего и говорю - всей схеме необходимы разделители.

>Если уж решил, что будут произвольная длина кодов, то без разделителей не обойтись.

>И если разделитель такой ёмкий и характерный, это таки победа.

>Правда остаётся вопрос как им отбивать числа имеющие в оконцовках единицы.

>Однако, если максимум подряд идущих единиц - две,

>то разделителем может стать, например 1110111. Тоже вполне неплохо.

А причём тут байты? Разделитель можно юзать и в бинарных данных.

С разделителем '11', такое уже не прокатит, потому что появляется многозначность:
100100001111010011101001010
10010000[11][11]0100[11]101001010
100100001[11]101001[11]01001010

А вот с разделителем '011', данные вида:
10010000101110100101101001010
могут быть однозначно разбиты на три числа:
100100001[011]101001[011]01001010

>Ну так в чистом виде по идее у тебя должна появляться более громоздкая запись.

>Вся писька в том, чтобы в этой громоздкой выделить некий инвариант,

>который можно вынести за рамки, тем самым получая хотя бы 1% сжатия.

Я же писал выше, что даже, если подсчитать частоты нахождения комбинаций '01' и '10', и сжать их тем же кодом Хаффмана,
длина сжатого представления числа в фибоначчиевой системе - получается примерно равной,
длине представления этого числа в двоичной системе, а то и больше.
Поэтому, и сжать не получается.

Кстати, хотя функция f(x) = x! растёт быстрее, чем f(x) = 2^x,
факториальная система счисления - ещё больше цифр выдаёт на выходе: https://rextester.com/OQP66610
Поэтому данные представления числа в этой системе - тоже избыточны.
Но я не знаю как насчёт энтропии этих данных, возможно они будут более сжимаемы.

>Опять же, это дискретка известная, там "оптимальным" считается нечто между 2 и 3.

>Тернарная система не взлетела по сугубо инженерным причинам, ну и плюс к ней алгебру логики сложнее прикручивать.

Троичная система счисления, считается оптимальной, потому что ln(x)/x,
где x - основание системы счисления, имеет максимум при e.

Если проще, можно рассмотреть пример: у нас есть 60 дощечек, на которых можно написать повторяющиеся цифры - как нужно поступить, какую позиционную систему выбрать, чтобы при помощи этого набора выразить максимальное количество чисел? Можно сделать по 30 нулей и единиц, тогда в двоичной системе можно будет записать 2^30 - чуть более миллиарда различных чисел. Если сделать по 20 штук "0", "1" и "2" - то 3^20 - почти 3,5 миллиарда чисел в троичной системе. 4 цифры на 15 разрядов: 4^15=2^30, максимум функции пройден, дальше на убыль: 5^12 - менее четверти миллиарда, 6^10 - 60 миллионов, наконец 10^6 (привычная нам десятичная система) - миллион, совсем смех. 12^5 - вчетверо меньше... А можно просто 60 разных цифр и один разряд, как вавилоняне - вот и будут лишь числа от 0 до 59.

В непрерывном случае максимум приходится на число e=2,718...,
так что основание 3 выглядит лучше всех, 2 и 4 - одинаково чуть похуже: http://phg.su/basis2/X51.HTM - наглядно.

Вот в этой "википедии": https://ru.wikibooks.org/wiki/Системы_счисления ,
расписано про "зависимость плотности записи информации от основания системы счисления"
и вот тут ещё: http://igorypimenov.narod.ru/Psichophisical_model.pdf
В конце 3 страницы и в начале 4.

>Ну вот это совершенно точно нет, опять же с пруфами.

>Впрочем только для целых чисел. Никто на самом деле не мешает считать полторашками, например.

Поэтому и фигово.
Глянул я, в общем, последовательность из 1000 додекаэдральных чисел: https://oeis.org/A006566/b006566.txt
Растёт она не очень быстро, но быстрее чем кубы.
Корень кубический, в три раза короче по битовой длине, чем сам куб, но по первой гипотезе Поллока,
их 9, надо, этих кубов: https://ru.wikipedia.org/wiki/Гипотезы_Поллока
а значит длина двоичного представления разложенного числа - должна быть ещё длинее чем само число.
Фак.

>>63044
Решил отпердолить троичную систему счисления, чтобы вконец разочароваться в этой идее...

Нашёл вот эту многообещающую статью: https://arxiv.org/ftp/arxiv/papers/1201/1201.5603.pdf

Выдернул с неё основание 3, префиксный код, и запилил это: https://rextester.com/YPFE4643
Заодно уж заделал функцию для конвертации числа в b-ричную систему счислени и из b-ричной - в десятичную.
Добавил функцию для кодирования-декодирования, при помощи префиксного кода:
https://ru.wikipedia.org/wiki/Префиксный_код
https://ru.wikipedia.org/wiki/Код_Хаффмана
и функцию для подсчёта нулевых и единичных бит, а также их комбинаций.
Можешь ткнуть в код и нажать F8, чтобы запустить.

Видно, что нихуя не работает, сжатие, как описано в статье выше,
кроме как для случая с числом 1358, указанном в статье.
Попытался найти закономерность, и стало очевидно,
что количество бит закодированного префиксным кодом троичного представления числа,
падает тогда, когда троичное представление этого числа - содержит много двоек.
В любом случае, закодированное префиксным кодом - троичное представление рандомного числа,
хоть и избыточно (длина строки и объем данных больше, чем у двоичного представления),
но тем не менее, оно содержит больше нулей, чем двоичное представление этого числа,
а значит меньше грузит линию при передаче данных.
Разве что в этом и профит, блеать.

А вот как сжать рандом ёбанный, или крипторандом - хз.
Чё-то вертится на уме, опять же, какой-то закольцованный йоба-LSFR, с динамической адресацией, снижающий энтропию входных данных...
Его, кстати, можно было бы и закодить в виде таблицы замен, но не думаю, что оно что-то даст.

>>63097

>Чё-то вертится на уме, опять же, какой-то закольцованный йоба-LSFR, с динамической адресацией, снижающий энтропию входных данных

Опять же это надо как-то изящно обосновать.
Я интересу ради попробовал несколько тысяч генераторов рандомных (в принципе любой рандомайзер по сиду подойдёт - тупо делаешь их множество и собираешь в списки\массивы выдачу) настроить под поиск в них удачной комбинации бит - увы и ах, попаданий было ноль на миллионы проверок, а времени на одном потоке ушло овердохуя.

Вообще, если задачу формулировать в таком варианте, то у нас есть целая гора очень хороших и работающих повсеместно алгоритмов сжатия. Не доверять им я смысла не вижу. Соответственно всю первичную работу можно поручать данной группе алгоритмов (например в zip запаковать с максимальным уровнем сжатия).

Далее мы сталкиваемся с обилием энтропии.

И тут мы можем постулировать два случая:
1) Всевозможные рандомайзеры с сидом совершенно явным образом задают огромное количество информации.
Нужен буквально следующий набор:
<код типа рандомайзера> <сид> <оффсет байт/бит от начала выданной последовательности> <собираемое число байт/бит начиная с оффсета>
Если брать сдвиг по битам и ещё, например, добавить пару флагов вроде реверсивного взятия, инверсии и каких-нибудь перетасовок, то такая схема очевидно позволит записать довольно много данных буквально несколькими байтами (для пущего эффекта это всё можно вырезать из общей последовательности и записать позицию с которой вырезание произошло, чтобы при декодировании вклеивать), которые ещё и отдельно хранить можно.
Но насколько ничтожна вероятность что для рандомного куска байт будет выгодное нам попадание? С виду проверять чистые байты/биты - гиблое дело. Но можно попробовать что-то типа регексов по типу: "идём от текущей позиции, делая приращение по условной единице, если среди всех генераторных схем случилось попадание позволяющее после всех манипуляций сэкономить хотя бы один байт - попробовать движение дальше покуда есть приращение сэкономпленного, как только матчинг пропадает то откатываемся на шаг назад и делаем вырезку данных, после чего продолжаем опять".
Это заведомо не будет иметь большой вычислительной эффективности, но в случае попаданий очевидно будет иметь эффективность сжатия.

2) Можно устроить вишмастер для уже сжатых данных, по какой-либо схеме рандомности разбросав байты. Если мы можем это преобразование записать конкретным образом и оно обратимо, то можно просто перебирать шатание байтов: ушатать и проверить происходит ли сжатие с указанной эффективностью не ниже минимальной.
Тут достаточно:
<список ранее применённых схем шатания байт <код такой схемы>> <было ли сжатие>.
В данном случае мы уже точно имеем очень медленное приращение побочных данных, плюс можем обеспечить рекурсивность. Опять же, вероятность того что цепочка рандомизаций выдаст результат который подарит новые грани сжатия явно ненулевая, но и едва ли великая. Вычислительная сложность также может быть пиздецовой. Впрочем люди и софт крупный могут компилить вручную, если можно будет распечатать крупный файл из нихуя, то энтузиасты подождут обработку.
Сам ещё не пробовал, на выходных может будет окно - запущу в каком-нибудь примитивном виде поглазеть.

Ну и в общем, если мы по обоим случаям можем обнаружить и обосновать ненулевую вероятность сжатия, да ещё и которую можно на простом ПеКа выявить менее чем за час работы - бинго. Далее опять же рекурсивность можно будет врубать и жать до посинения.

----
Сейчас ещё прикинул - можно покопать в сторону лосслесс, но хитрым образом. Например, есть схема сжатие джипегов через косинусоиды. Выигрыш там огромный в том числе для особо сложных данных. При этом при правильной кодировке можно воспроизводить цельный битмап каждый раз, пусть и с потерей ряда данных.
Однако, можно сделать подобное, а те самые теряемые данные банально заинвёртить относительно восстанавливаемого массива. Тогда мы получим:
<пережатое косинусоидами или чем подобным> + <массив дополнений до лосслесс>
Последний можно попробовать повторно пожать традиционным сжатием, разбить на куски и повторить текущую процедуру итд.

>>63105

>LSFR

Просто к слову пришёлся как один из наиболее понятных мне алгоритмов для псевдорандома. Там схема явным образом задаётся полиномом и сидом, что собственно и позволяет сколько-то компактно описать рандомизатор.

Сегодня вероятности подрочил немного - словарные схемы в чистом виде выглядят совершенно гиблым делом.
Однако, если "словарь" будет каким-то образом генерироваться на основе поданного на него блока байтов, где из поданного блока словарь в компактном виде будет записывать от 30% блока - собственно бинго. Осталось только структуру подобрать какую-нибудь и чтобы граф её трансформаций можно было в один-два байта уместить.
Хз, наверное в течение недели напишу на чём-нибудь.

Опять же, всё упирается в мат.ожидание:
- словарь может содержать лишь ничтожную часть от возможных комбинаций байтов заданной длины
- тем не менее в пределах блока (5, 7, 15 и более байт) реальная комбинация будет на порядок более ничтожной от всего пространства возможных комбинаций по столько же байт
- соответственно, если мы можем соорудить словарь чьё "адресное пространство" сколько-то больше поданных на него блоков, а сам подготовленный словарь вместе с трансформациями будет иметь в себе критически выигрышный процент от взятых для текущей итерации блоков, то будет хорошо

Общая схема примерно так:
<полученный сид словаря> <настроечная структура> <список блоков фиксированного размера <блок байтов>>

Настроечная структура в общем виде должна иметь один-два бита для типа используемых словарей, и далее набор бит соответствующий каждому блоку: единица означает что данный блок должен быть декодирован по словарю, ноль - что должен восприниматься как есть.

В данном случае мы должны получить гонку между приращением настроечной информации на список блоков против выигрыша от скольки-то сокращённых блоков.
Алгоритм должен априори гарантировать что n-% и 100% попадание блоков в словарь даст меньший объём чем исходный список. А раз так то нужно лишь убедиться что общая вероятность попадания не меньше собственно n%.
Фух, хоть сформулировал чего ищу вообще.

>>63121
>>63122
>>63124
Короче, посоны!
Думал, я, думал насчёт негэнтропии... И не придумал ничего лучше...
Кроме как... ВНЕЗАПНО... НЕГАЦИИ ЭНТРОПИИ!

Опишу алгоритм "негэнтропийного сжатия" так, как я его вижу.
Идея следующая...

Пусть у нас будут - несжимаемые данные, в которых количество единиц и нулей - одинаково, а их распределение - равномерно.
И пусть этими данными - будет некая 32-битная строка:
00011011111001000001101111100100 (длина 32 бит, в ней 16 единиц и 16 нулей, хуй пойми где).

Проводить негацию будем там, где обнаружено - наибольшее количество единичных бит.
Для этого, придётся производить подсчёт единичных бит, затрачивая время и вычислительные мощности,
но нам на это похуй, ведь мы хотим сжать НЕСЖИМАЕМЫЕ ДАННЫЕ,
и профит свистящих куллеров на проце, в том,
что "НЕСЖИМАЕМЫЕ, БЛЯДЬ, ДАННЫЕ",
в итоге, должны превратиться в СЖИМАЕМЫЕ.

Итак...
Для начала, определим максимальное значение блока данных, по формуле:
n = 2^⌊ln(bitlength)/ln(2)⌋;
где
n - длина блока в битах,
^ - возведение в степень,
⌊x⌋ - округление x к меншему (floor),
ln - логарифм по основанию e,
bitlength - длина блока данных.

КОД (Python3):

>LEN = 32

>import math;

>n = int(math.pow(2, (math.floor((math.log(LEN)/math.log(2)))))); #максимальное число блока бит, для данных длиной LEN бит.

>print(n); #32

Вроде, работает правильно.

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

TL;DR
ОПИСАНИЕ АЛГОРИТМА:
Шаг 1.
Считаем единичные биты в блоке размер которого определён выше (32 байт). Стартовый оффсет - 0;
Если количество этих единиц больше половины блока - то отмечаем бит негации блока, и производим негацию ВСЕГО БЛОКА.
Тогда, количество единиц должно уменьшиться, а информационная энтропия - сместиться.
Если количество единиц меньше либо равно значению половины блока - то не трогаем его и оставляем как есть.

Шаг 2.
Ещё один момент... Рассмотрим пример: пусть есть 16 бит данных, и блок по 8 бит.
00001111 11110000 (два блока по 8 бит)
4 4 (количество единиц в каждом блоке - по половине блока, и как-бы пропускаем, и не трогаем)
1111 1111
8 (но здесь их - намного больше, стартовый оффсет 4-й бит, длина блока 8 бит)
Поэтому, на шаге 2 - расширяем Шаг 1.
Производим сдвиг блока (32 байт) на половину (16 байт). Стартовый оффсет не 0 уже, а 16.
И ещё в одном блоке (32 минус 16, то есть, до конца данных) просчитываем количество единиц.
Дальше - аналогично. Либо негация, либо нет. И бит один отметить.
Однако даже если там, в этом урезанном недоблоке 32-битном,
будут все 16 единиц, количество их будет равно половине полного блока (32/16 бит),
и негацию можно не проводить, по условию,
как и можно не проводить эту итерацию вовсе,
ибо ноль 32-битных блоков здесь, всего.

Шаг 3. Половиним длину блока. Было 32, стало 16.
Теперь, как и в Шаге 1 - считаем единицы в двух блоках по 16 бит. Стартовый оффсет 0-й бит:
0001101111100100 0001101111100100 (их по 8, этих единиц, в каждом). Следовательно - никаких негаций. Бит негаций - 0.

Шаг 4. Аналогично шагу 2. Сдвигаем блок на половину (было 16 бит), теперь (с стартового оффсета 8, и по 16 бит на блок) получаем:
00011011 1110010000011011 11100100
Как и в Шаге 1 - считаем биты для каждого 16-ти битного блока (их всего один, он посередине).
Единиц в нём - 8 и менее (где по бокам, в недоблоках). Поэтому - никаких негаций, по условию. Бит негаций - 0 и здесь.

Шаг 5. Снова половиним длину блока. Было 16 бит, стало 8. Стартовый оффсет - 0;
По 8 бит блок:
00011011 11100100 00011011 11100100
Как в шаге 1, считаем биты в этих 8-ми битных блоках. Единиц этих по 4, в каждом блоке, и это ровно половина блока.
Значит - никаких негаций. Бит негаций - 0. Ебать-копать, да эти данные, блядь, внатуре - какие-то несжимаемые!

Шаг 6. Сдвиг на половину блока. Был блок длиной в 8 бит, стартовый оффсет теперь 4-й бит, а не 0-й, и 8 бит - длина блока, прежняя.
0001 10111110 01000001 10111110 0100
Теперь, как и в шаге 1, считаем биты для каждого 8-ми битного блока.
1 6 2 6 1 - и вот здесь, можно провести негацию двух блоков из трех (не считая недоблоки)! Биты негаций: (1) 1 0 1.
Первый бит означает, что будут негации, дальше бит, негации или не негации каждого последующего блока из 8-ми бит.
Теперь, производим саму негацию:
0001 01000001 01000001 01000001 0100
Почему негации? А по условию, потому что количество единиц в двух блоках зашкаливает.
При длине блока в 8 бит, и половине допустимых единиц (4), там их по 6, этих единиц.
На выходе - более сжимаемые данные, так как после негаций имеем нарушение равномерного распределения бит.

_____________
Как и в шаге 3, можно было бы продолжать половинить блок, углубляясь, и просчитывая единички в более мелких блоках (со сдвигом),
но здесь уже смысла негировать - нет,
и очевидно, что мы получили строку с наименьшей информационной энтропией
(в ней - много нулей, и мало единиц).
Если повторять Шаг 3, в отсутствие негаций, то бит негаций каждого раунда - будет 0.

Шаг 7. Теперь... Пишем дополнительные данные, в конец этих уже "сжимаемых данных":
Приведу таблицу проведённых выше операций:

Старт длина блока биты
0 32 (0)
16 32 (0)
0 16 (0)
8 16 (0)
0 8 (0)
4 8 (1)101(биты негаций или не негаций последующих блоков по 8 бит, следующих со старта)
0 4 (0)
2 0 (0)
и т. д.

Промежуточный результат:
00000110100 - это дополнительные данные (информационная избыточность).

После всего этого, следовало бы добавить ещё и длину самих этих вот - дополнительных данных.
Идеальным вариантом, я вижу гамма-код Элиаса,
позволяющий закодировать любое число неопределённой длины:
https://ru.wikipedia.org/wiki/Гамма-код_Элиаса
но так как длина их неопределена, как и длина числа этого, то код - реверсивный.
То есть: 00000110100 (11 бит); 11 -> 000 1 011 (Код эллиаса) -> реверс кода: (1101000) -> в конец строки.

Результат:
0001 01000001 01000001 01000001 0100+
00000110100+
1101000 =
00010100000101000001010000010100000001101001101000 (окончательный результат преобразования).

Теперь, рассмотрим их...
Эти данные хоть и избыточны (длина их более 32 бит), но они уже не "несжимаемы",
напротив, они уже выглядят "более сжимаемыми", поскольку единиц меньше чем нулей.

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

Вроде, должно работать, совместно с сжатием, и вроде как ещё, должно давать возможность - многораундового сжатия.
Алсо, на базе развёртки данных из зажатой инфы, ИМХО, можно было бы замутить и некий - порождатель инфы.
Но я чё-т ебу, как всё это закодить... Это же не проект не на один день, и меня уже заебало.
В общем, кто допилит - шнобелевку получите. Дерзайте. Авось модель Вселенной на флешках будем носить.

>>62709 (OP)
Есть идея сжать данные так:

1. Берём блок данных, пусть это будет двоичная строка: 1101101010010100010001
Считаем количество единичных бит: 10
Делим это число (10 бит) на длину двоичных данных (22 бита): 10 / 22 = 0.4545454545...
Если результат больше 0.5 - негация и + бит 1,
иначе оставить как есть и + бит 0 (этот случай).
Результат: 01101101010010100010001 (23 бита)

Таким образом, для блока данных в N бит,
количество значений уменьшается до 2^(N-1),
часть из которых представляет из себя несжимаемые данные
(значения, с биномиальным распределением бит, единичных бит в которых ровно 50%).
Этих данных - ровно половина из диапазона 2^N.
Остальные возможные значения содержат меньшее число бит.

2. Нумеруем позиции бит по порядку:
01101101010010100010001
01234567890123456789012 - индекс
0`````````1`````````2`` - второй разряд, чтобы вместить индексы - в одну цифру

3. Пишем позиции единичных бит:
1 2 4 5 7 9 12 14 18 22 - значения растут

4. Двигаем указатель на +1 от текущей позиции, и пишем расстояние к следующему биту:
1 0 1 0 1 1 2 1 3 3 - расстояние от последней позиции +1 до следующего единичного бита - это количество нулей до следующей единицы.

Как видим, вторая последовательность содержит более повторяющиеся значения.
Максимальное значение - 3, три нуля максимум, между единицами.

5. Считаем количество повторов:
0 - 2
1 - 5
2 - 1
3 - 2

6. Сортируем по количеству повторов:
1 - 5
0 - 2
3 - 2
2 - 1

7. Формируем префиксный код:
1 - 0
0 - 10
3 - 110
2 - 111

8. Кодируем последовательность с шага 4 префиксным кодом:
0 10 0 10 0 0 111 0 110 110
В одну строк всё это:
010010001110110110 - 18 бит.
изначальная строка:
01101101010010100010001 - 23 бита.

Сжатие 5 бит получилось.

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

Упор сдесь делается на то, что в данных из пункта 4: [1 0 1 0 1 1 2 1 3 3]
должно бы быть много одинаковых повторов,
даже для несжимаемых данных - данных с биномиальным распределением бит.
Иначе, чем меньше бит, тем меньше единичных бит, тем короче эта последовательность,
тем меньше вариантов чисел в этой последовательности,
и тем более коротким префиксным кодом можно закодировать эти варианты.

>>64272
>>64284

Немного разовью єту идею.
Префиксный код формируется так:
0 (наибольшая частота повторов чисел в массиве)
10
110
1110
11110
11111 (наименьшая частота повторов чисел в массиве)

А что, если вместо нуля - гамма-код эллиаса для единиц прописать?
Ведь когда в массиве [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 3]
много нулей подряд, (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
это значит что там нет нулей, между единицами и идут сплошные единицы, подряд: 111111111111
Массив этот - образуется из значения: 1111111111110111110001 (если его биты не инвертировать),
и в точности отражает количество нулей, перед следующей единицей.

Если использовать гамма-код Элиаса, то эти нули, можно записать не так:
000000000000(12 бит)
а так
00001100 (8 бит)

Очевидно, что в значении с малым количеством единиц,
могут быть большие расстояния между ними, в виде нулей.
Их количества будут велики.
Вероятность нахождения же большого числа единиц рядом - мала.
Но всё-же. Их может быть много по две. По три, по пять, по десять.

Тем не менее, можно было бы делать переключения префиксный код, замкнуты на ноль, исключив при этом - сам ноль.

01 - ноль и следующий префиксный код.
001 - по одному нулю дальше, до единицы.
0001 - дальше - следует код Элиаса, обозначающий количество нулей.
00001 - код Элиаса, для повтора предыдущего кода.

Например, один ноль.
0 != 0 = 01
00 != 00 =0010
0000000000000000000000000 !=0000000000000000000000000=00010000011001
2222222 !=11111111111111 =1100001000101
11 выбрано для префиксного кода (0 - 0, 1 - 10, 2 - 11)

>>64427

>Ты всегда берешь первый элемент фиксированным?

Да. Это бит со значением "0". Вот же код, тут: >>64071

>Тогда пусть первый всегда 1:

>11 00 10 01 10 01 - вот она зациклилась и не вернёт мне 11

>Что я делаю не так?

Ты про зацикливание последовательности изменения первых двух бит что-ли?
Не пойму где ты там группы увидел...
Со стартовым битом 0, оно первые два бита зацикливаются как-то так:

>11 10 11 10 11 10, и никаких выебонов.

>Ну и в любом случае без оценки х от длины последовательности,

>даже если все, что ты написал, правда, пользы считай нет.

Я увидел пользу этого простого преобразования в следующих двух свойствах:
1. Оно реверсивно и его можно обратить, получив на выходе изначальное значение,
по строке результату, числу, которое не так уж и велико (из-за зацикливания).
2. Это преобразование ИЗМЕНЯЕТ количество единичных бит,
а значит изменяет информационную энтропию Шеннона.

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

>Если размер одной группы 2^х, то тебе надо передать число от нуля до 2^х-1, т.к. ты не знаешь, какое число из группы тебе нужно.

>По сути это анонимно тому, чтобы разбить числа на какие-то группы, и передавать их как сумму базы и номера в группе.

>Скажем как передать число 987654321 как 900000000 и 87654321, потому что 900000000 хорошо сжимается.

>В твоём варианте к тому же не факт что группы будут сжиматься одинаково хороши,

>о значит если в одной группе больше элементов, чем в другой, то ей понадобится лишний разряд для записи порядкового номера элемента в группе

На самом деле, ТАМ НАМНОГО КОРОЧЕ размер цикла, если стартовым значением взять нулевой бит.

Как видишь, каждый раз, 32-битное значение, выдаёт себя же, через 31 шаг.

>i = 31 True

>строка 124

Возьми код тот, поменяй значения на свои, внутри него (строка 98),
и перезапусти его пару раз, в общем поиграйся, и поймёшь.
Может даже новые закономерности увидишь какие-нить.

>>78833

>Я же, думаю над тем, как рассмотреть пиздатую шестнадцатиричную последовательность, в качестве числа,

>с последующим его разложением или уменьшением так,

>чтобы его МОЖНО БЫЛО ВОССТАНОВИТЬ,

>а в крайнем случае ПОДОБРАТЬ БРУТФОРСОМ, используя вычислительные мощности.

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

Тогда, любой блок данных, можно запхнуть в хэш-таблицу, читай в JSON-объект,
где эти данные будут доступны по хэшу, как по ключу.

Но что если эти данные могут быть потеряны, а хэши останутся?
Тогда, их, наверное, можно было бы, тупо - сбрутфорсить.
И из-за ограниченной длины данных, количество комбинаций брутфорса было бы снижено.
Но в памяти всплывают сразу же коллизии к хэшам...
И если взять пример с CRC-32 суммами контрольными, то схема сразу же идёт по пизде.
Потому что, вот что: https://ru.wikipedia.org/wiki/Сжатие_без_потерь#Сжатие_и_комбинаторика

>Легко доказывается теорема.

>Для любого N > 0 нет алгоритма сжатия без потерь, который:

>Любой файл длиной не более N байт или оставляет той же длины, или уменьшает.

>Уменьшает некоторый файл длиной не более N хотя бы на один байт.

То есть, результат применения такого алгоритма (читай к хэшу, как к результату применения хэш-функции),
может выдавать данные (хэш), которые могут быть развёрнуты в исходные данные, МНОГОЗНАЧНО
(да-да, есть коллизии хэш функции).
И некоторые данные, определённый алгоритм сжатия, может уменьшить, а вот некоторые данные - может и УВЕЛИЧИТЬ.

Поэтому, чуток ниже, есть приписочка:

>Впрочем, данная теорема нисколько не бросает тень на сжатие без потерь.

>Дело в том, что любой алгоритм сжатия можно модифицировать так,

>чтобы он увеличивал размер не более чем на 1 бит:

>если алгоритм уменьшил файл, пишем «1», потом сжатую последовательность, если увеличил — пишем «0», затем исходную.

Если же результатом применения такого алгоритма сжатия, будет ХЭШ, ограниченной длины,
то хэш этот может иметь, две, три, пять, сто пять коллизий, в пределе определённого блока данных.

А это значит, что при попытке развёртки данных, при брутфорсе этих данных из имеющегося хэша,
можно получить, внезапно, ДРУГИЕ ДАННЫЕ, которые могут иметь такой же хэш.
Возможно они могут быть более длинными, нежели исходные данные,
и тогда, в этом случае, имело бы смысл, указать ДЛИНУ исходных данных, вместе с хэшем,
для однозначного нахождения исходных данных, по хэшу, без коллизий,
а также имело бы смысл РАЗРАБОТАТЬ алгоритмы хэширования,
позволяющие хэшировать ОДНОЗНАЧНО, данные определённой длины в хэш (блять, а так разве возможно?),
так, чтобы, путь даже и приложив вычислительные мощности,
зная хэш и длину, опять же, ОДНОЗНАЧНО - восстановить данные из более короткой их записи (хэш+ДлинаДанных).

Всё это кажется абсурдны, но мне чё-то кажется, что данные, несжимаемые данные,
можно таки сжать, если каким-то алго, можно было бы,
сдвинуть их биномиальное распределение бит 50%/50% в какую-либо сторону,
скажем 80% нулевых бит к 20-ти % единичных, а потом сжать нули,
и приписать ещё один бит,
мол сырые ли это данные (0), или же данные, которые следует конвертнуть назад, через алго (1).

>>78847
Немного не по теме, но интересно.
Ты дал кратчайшее определение, через мощность множеств,
но моё определение по-моему более краткое, и может быть модифицировано, включая ноль.

Погуглил на тему нуля немного, и нашёл кучу срачей.
Например:

>ноль не является натуральным, потому что это не природное число, ноль конфет нельзя съесть, а одну конфету - можно.

>номера домов не начинаются с нуля, потому что первый дом - имеет номер 1, и нет нулевого дома. Ноль - означает отсутствие дома, это не натурально, и не природно (nature).

И тому подобное...

https://ru.wikipedia.org/wiki/Натуральное_число#Место_нуля
Здесь, расписано о двух определениях ряда натуральных чисел, один из которых включает в себя ноль.

Мне кажется, что чтобы разобраться в том, является ли число ноль - числом натуральным,
надо взять ВСЕ СВОЙСТВА НАТУРАЛЬНЫХ ЧИСЕЛ:
https://scienceland.info/algebra8/natural-number
и проверить, не нарушаются ли они, если включить в них ноль?

Например, если взять такое вот,
простое и краткое определение целых чисел:
"целые числа - это натуральные, а также натуральные - со знаком минус..."
И 0 если включить в натуральные, то соответствующее ему число со знаком минус, будет -0,
что уже как-бы не совсем то, ведь это два числа, которые равны.
Надо посмотреть, не нарушаются ли другие, более фундаментальные свойства и определения, не только натуральных чисел, но и чисел связанных с натуральными,
если включить ноль в натуральные, и если его не включать.

Ну и, наконец, следовало бы дать чёткое и однозначно определение, безо всех этих вот, расхождений.

Также, ноль, число особенное, на него делить нельзя.

И ещё... Мне кажется, что ряд натуральных чисел, начинается с 1, просто потому что этот ряд можно представить группой, в которой порождающий элемент 1, а любое следующее - есть прибавление 1 к предыдущему.
0, как порождающий элемент, уже не канает,
потому что сколько не прибавляй 0 к 0, будет 0,
а даже если к другому числу прибавить 0, будет оно же, и группа не будет порождаться.
Короче, какой-то сдвиг во свойствах начинается, если включить 0, и если это не какие-то фундаментальные сфойства, которые расхуячат всю арифметику и алгебру, и математику, и матан,
то 0 можно включить, банальной коррекцией определений,
безо всяких расхождений, неоднозначных.

>>62709 (OP)
Я пытался найти эту последовательность в OEIS, но так и не нашёл.
Похоже, что я открыл нечто новое, что требовалось бы исследовать.
Исследовать, как при помощи вычислительных мощностей (тупо пробрутить, скажем, до дохуллиона, с хуем значений),
так и исследовать, при помощи специалистов,
пытаясь распознать закономерности,
и пытаясь найти способы преобразования этих значений,
в какие-нибудь другие, сворачиваемые ряды.

Итак, представляю вашему вниманию, эту последовательность.
Она имеет следующий вид:

>1, 2, 3, 5, 6, 9, 10, 12, 7, 11, 13, 14, 19, 21, 22, 25, 26, 28, 35, 37, 38, 41, 42, 44, 49, 50, 52, 56, 15, 23, 27, 29, 30, 39, 43, 45, 46, 51, 53, 54, 57, 58, 60, 71, 75, 77, 78, 83, 85, 86, 89, 90, 92, 99, 101, 102, 105, 106, 108, 113, 114, 116, 120, 135, 139, 141, 142, 147, 149, 150, 153, 154, 156, 163, 165, 166, 169, 170, 172, 177, 178, 180, 184, 195, 197, 198, 201, 202, 204, 209, 210, 212, 216, 225, 226, 228, 232, 240, ...

и она была сгенерирована этим кодом на JavaScript:

>//count number of 1-bits, and 0-bits.

>function count10(str){

> var _1 = _0 = 0;

> for(var i=0; i<str.length; i++){

> if(str==='1'){_1++;}else{_0++;}

> }

> return [_1, _0];

>}

>

>var s = '';

>for(var len=0; len<=8; len++){

> for(var val=0; val<Math.pow(2, len); val++){

> var value = val.toString(2).padStart(len, '0');

> var OnesAndNulls = count10(value);

> console.log('val', val, 'value', value, 'count10(value): '+count10(value));

> if(OnesAndNulls[0] === OnesAndNulls[1]){

> s+=val.toString()+', ';

> }

> }

>}

>console.log(s);

Как можно видеть, это числа, у которых число единичных бит, равно числу нулевых бит.
То есть числа, которые являют собой несжимаемые данные.
Негация этих чисел - даёт такж несжимаемые данные, с тем же числом единиц и нулей.

Первое, что взбрело в голову, это выставить len<=16, вместо 8, и получив 17576 чисел на выходе,
сунуть их в массив, сделав доступными по индексам, являющимся номером по порядку.
Как-бы полагая, индексы, идущие по порядку, будут являть собой, в большинстве своём - сжимаемые данные,
в которые можно биективно преобразовать эти вот, несжимаемые данные,
а потом сжать уже сжимаемые данные, которые должны сжаться.
Похуй на то, что где-то единиц больше чем нулей, а где-то меньше чем нулей,
негация может свести это дело к меньшему числу единиц, и большему числу нулей,
с возможностью сжать потом нули.

Вводя в гуголь последовательность, я вижу какие-то другие последовательности, с похожими числами.
Воможно, эту последовательность можно свести к ним. А быть может она и уникальна.
Подумайте, что можно сделать с этой хуйнёй,
ведь прон сам по себе не сожмётся, если будете сидеть и пучкать попусту, блядь.

>>62709 (OP)
Анон, я вот одного не пойму...
Какого хуя процессора делают на транзисторах?
Они же предназначены для управления током, и через транзисторы в открытом состоянии - постоянно течет электрический ток, нагревая их, и процессор вцелом.
Почему нельзя попросту кодировать инфу, наличием или отсутствием электрического поля на входах и выходах?
Почему нельзя создать электронный компонент, наподобие транзистора, который содержит внутри подвижный заряд, и изменяет своё состояние, и потенциалы на выходе, в зависимости от потенциала на входе, но через который ток не течёт?
Скажем так, представь себе, что внутри элемента - содержится какой-нибудь, блядь, заряженный и пиздатый ион, который настолько пиздат, что не может принимать и отдавать электроны, но может двигаться внутри элемента, от входного контакта к выходному, скажем.
Тогда, такой элемент, мог бы переключать состояния в зависимости от потенциалов на входах, порождая потенциалы на выходах, и всё это - без протекания тока, а значит и без существенного нагрева.

Другим аспектом нагрева, является принцип Ландауэра, который гласит о том, что утеря бита информации - приводит к выделению некоего количества тепла: https://ru.wikipedia.org/wiki/Принцип_Ландауэра
Нивелировать этот нагрев можно было бы при помощи обратимых вычислений: https://ru.wikipedia.org/wiki/Обратимые_вычисления

Среди обратимых логических вентилей, то что я нашел, это:
CNOT, вентиль Фредкина, и Вентиль Тоффоли.
CNOT сама по себе, хоть и обратим, но логическая операция СNOT не являет собой полнофункциональный логический базис (булев базис), а вот пара CNOT и NOT - уже являет.
Вентили Тоффоли и Фредкина, являют собой булев базис, и могут быть использованы для построения AND, OR, и NOT.

Однако, если рассмотреть таблицы истинности вентилей Фредкина и Тоффоли поближе, можно видеть, что несмотря на обратимость преобразований бит (из комбинации выходов, по таблице, можно однозначно восстановить комбинацию входов) - само преобразование входной информации в выходную - не является обратимым, потому как число единичных бит в каждом состоянии - не является одинаковым, биты либо появляются изниоткуда (что требует энергии), либо теряются (что приводит к нагреву по принципу Ландауэра).

Чтобы решить этот вопрос, предлагаю рассмотреть таблицу истинности, скажем, вентиля Тоффоли, поближе:
https://ru.wikipedia.org/wiki/Вентиль_Тоффоли

ВХОДВЫХОД
000 000
001 001
010 010
011 011
100 100
101 101
110 111
111 110

Из неё очевидно, что максимальное число единичных бит на входах и выходах - равно 5.
Значит, в первом случае, для полностью обратимых вычислений, в которых информация не появляется и не исчезает, эти 5 единиц (читай заряды), должны бы быть перемещены на неиспользуемые контакты элемента:

000 000 11111
001 001 00111
010 010 00111
011 011 00001
100 100 00111
101 101 00001
110 111 00000
111 110 00000

Таким образом, число единичных бит внутри элемента, постоянно, при каждом его состоянии.

Можно добавить ещё один неиспользуемый контакт, содержащий единичный бит, чтобы элемент был 12-ти выводным, и чтобы число зарядов внутри элемента компенсировало друг-друга, потому что единичный бит - это негативный заряд вблизи контакта, создающий поле, а нулевой бит - его отсутствие вблизи контакта, то есть читай - позитивный заряд:
000 000 111111
001 001 100111
010 010 100111
011 011 100001
100 100 100111
101 101 100001
110 111 100000
111 110 100000

Ну и конечно же, порядок бит на неиспользуемых контактах не является обязательным, ведь эти контакты не используются.
Таким образом, там может быть, например, какая-нибудь инверсия входов и выходов тоже:
000 000 111111
001 001 110110
010 010 101101
011 011 100100
100 100 011011
101 101 010010
110 111 001000
111 110 000001

Теперь, если посмотреть на числа:
000000111111
001001110110
010010101101
011011100100
100100011011
101101010010
110111001000
111110000001
можно видеть что это числа разрядности кратной 2, с равным числом единичных и нулевых бит в их двоичном представлении. Такие числа называются сбалансированными двоичными числами.

Используя всего 8 из них, можно было бы создать 12-ти выводный элемент, в котором инфа (единичные биты, заряды) не появляется и не исчезает, по которому ток не течёт, в котором инфа кодируется наличием или отсутствием потенциалов на входах и выходах, в котором состояния изменяются перераспределением зарядов между выводами, и который мог бы быть достаточно универсальным для построения любой булевой функции, так как по-сути это вентиль Тоффоли. К тому же, не так пиздато греющийся, как эти ваши транзисторы, сцука, гребучие.

>>117083

>возможно, сделать такой элемент значительно труднее (если вообще возможно, это мне неизвестно)

Судя по принципу работы, должно бы быть возможно, почему нет?

>при этом сам он значительно крупнее

наномизация ежжи

>а состояния меняет значительно медленнее

Мне кажется, что потенциалы электрического поля двигаются со скоростью света, в отличие от электронов, поэтому не должно бы быть проблем со скоростью. Переключение потенциала происходит за счет локального движения заряда внутри элемента, а это намного быстрее, чем протекание этого заряда по всей электронной цепи.

>транзистор это очень эффективная штука, которая очень просто устроена и легко производится в огромных количествах на маленькой площади

Именно так, владельцы корпораций один раз изобрели технологию фотолитографии, и теперь применяют только её, модифицируя и масштабируя. Но проблема протекания тока по транзисторам, их нагрев, и нагрев по принципу Ландауэра, за счет утери бит информации, в результате высокопроизводительных вычислений - остаётся открытой. Поэтому имеет смысл взглянуть на всё это с точки зрения разработки принципиально-новых технологий, ведь очевидно что вычислительная техника, в том числе и нейроморфная - это будущее всего человечества.

>разумеется, за скорость работы мы платим энергоэффективностью, тут и с транзисторами так

Я где-то слышал, что существуют ёмкостные и резистивные переключатели, изменяющие ёмкость или сопротивление в зависимости от входного - ПОТЕНЦИАЛА, а не тока. Это уже некое подобие полевых транзистоов, но и через них, и через полевые транзисторы - протекает ток, когда они в открытом состоянии.
Но в отличие от транзисторов, из тех же мемристоров уже можно строить нейросети, так как их последовательное соединение уже может служить инверсией нейрональной пороговой функции активации нейрона, или что-то типа того. Если расмотреть как работают нейроны, то можно видеть, что вдоль аксона тоже не протекает ионный ток, идёт волна ионного тока, а сами ионы движутся сквозь мембрану аксона, а потом перекачиваются назад натрий-калиевым насосом. То есть ионные токи в нейронах - минимальны, поэтому мозг потребляет не более 20 ватт, и не греется, в результате обработки тех же когнитивных данных, с учётом сетевого параллелизма нейросетей.

>Без протекания тока цепь не работает

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

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

А причем тут аналоговые вычисления? Те же компы из крабов-солдатов вида Mictyris guinotae, бильярдный компьютер, используют вполне себе дискретную логику, основанную на сполне себе дискретных логических элементах.
Аналоговые вычисления, скорее, производятся в биологических нейросетях, за счет аналоговых активационных функций, которые в отличие от пороговой n-арной булевой функции, могут оперировать не с булевыми значениями, а с рациональными значениями тоже. Та же сигмоидная функция, гиперболический тангенс, ReLU, Leaky ReLU, Softmax, и тому подобное - оперируют с аналоговыми сигналами, в процессе наложения электроэнцефалографических волн градуальных потенциалов, например. Я знаю, что существуют электронные элементы, выполняющие эти функции тоже, всякие там компараторы, нелинейные операционные усилители, диоды, нормализационные схемы, и тому подобное. Эти элементы, будучи включены в электронные схемы, могут выполнять аналоговые вычисления, эмулирующие нейросети, но они сложны для построения, и громоздки, в отличие от тех же транзисторных нейропроцессоров.
А с учетом того, что нейросетки можно эмулировать с помощью программного кода, так вообще проще кодом их и писать. Но всё это дело всё равно работает на греющихся транзисторах, блядь, которые жрут электрический ток, и которые в бошку не вставить, из-за этой ебанины, ебучьей.

Если же, для кодирования инфы в логичеких элементах, использовать наличие или отсутствие потенциалов, то с учётом того, что электрический ток через логические элементы не протекает, такая логика могла бы работать прямо в организме, с минимальным питанием той же бета-вольтаикой, или какими-нибудь глюкозными топливными элементами, а то и вовсе функционировать за счет протонного градиента на протонообменной мембране, как митохондрии, вырабатывающие энергию в виде АТФ, за счет протонного градиента.