Вот объяcни нахера ты эту пургу несешь?

Я ее делал в 2010 году. Тогда этот парадокс и выяснился. Но он очевиден и на примере натурального ряда 32-разрядных чисел.
В стандартном представлении одни только незначащие нули занимают море памяти, не говоря уже о совпадающих частях. Впрочем и это неважно при нынешних технологиях.

Не для поиска, а для хранения. Для поиска как раз вот этот комплементарный код. И получится аналог "ДНК" с прямым и комплементарныи кодом.

А вот это проверяется

Это вообще другая тема. Потом. Если захотите.

0000-00FF.

Вижу шестнадцатеричные цифры, нули и эфки.
Пустых байтов - не вижу! 

Отредактировано Лукомор (2023-07-08 13:28:03)

А они есть, и ты сам пишешь -

Ты еще на атомный уровень залезь! Договорились, что обсуждаем на логическом уровне. А на нем пусто=нуль

рассматриваются только символы

Точно! И еще нельзя говорить дырка, надо - отверстие, ибо не по феншую! И начхать, что символ ноль это символ отсутствия величины. Главное найти повод. Ты случаем гаишником не работал? 

На логическом уровне все разряды строго 0 или 1.

А также не по феншую говорить "наушники",  ибо правильное название
"головные телефоны".

То есть 11 и 10000001 - это будет одно и то же число?

В реальности у тебя в каждой точке последовательности идет ветвление, в каждой такой ячейке нужно хранить два адреса (на случай продолжения нулем или единицей), то есть два байта. Ветвление будет идти со скоростью 2^n, на 8-символьную последовательность нужно уже 510 байтов, вместо одного байта, если цепочку хранить в обычном виде. Для трехбуквенного (24-битного) слова счет ячеек пойдет на десятки мегабайтов.
В сторону уменьшения этого объема будет работать то, что не все последовательности будут реализовываться. Но сильно тут радоваться вряд ли стоит. В стандартной странице ASCII с русским и английским алфавитом заняты практически все позиции, ну допустим часть служебных символов можно убрать, но все равно даже самое радикальное сокращение не даст даже двукратного сокращения. Ну даже пусть в два раза и будет не 510, а 250 байт на букву - все равно на два порядка больше, чем при обычной записи.
Больший эффект может быть получен на уровне слов, но там уже ветвление от буквы к буквы будет идти со скоростью 256^n. Даже если в виде слова реализуется один из миллиона наборов букв, то для записи слова Шарпер нужны будут гигабайты памяти. И удаление дубликатов не поможет. В слове коловорот нельзя оставить одну о и исключить три остальных о. Потому как выходная адресация у каждой из них разная, это символы с разными свойствами, они не идентичны.

Да не совсем. Мы обсуждаем реальную работоспособность твоей таблицы, это важный момент в этой дискуссии.

Блиииин! Это символ наименьшего числа!

Я требую пытку Лукомором внести в список запрещенных!

Нет, конечно. Они ж отличаются во втором знаке.

1 И что страшного в десятках мегабайтов, если можно при необходимости реализовать терабайты со страничной организацией? Снова напомню про поля обогатительных центрифуг, когда "очевидная расточительность" обернулась чрезвычайной эффективностью. Проявление золотого правила механики - проигрываешь в расстоянии- выигрываешь в силе/производительности. Так что не вижу проблем в требуемом объеме, при том, что вся память однородная и не нужно гемороиться со спецустройствами ассоциативного доступа или изобретать средства против коллизий хеширования. Еще напомню, что изобюилиеп памяти привело к изменению программирования - циклы стали заменять повторяющимися коммандами. И иакая расточительность только приветствукется. И это все даже без учета наложений.

2 А с наложениями, еще интереснее. Вот картинка. Обратите внимание, что все числа начинаются с меньших разрядов  0 или 1 и накладываются вплоть до точки ветвления. Так что каждое следующее число ряда будет давать прирост всего на два адресных слова.

Совсем не так! Каждая словоформа, обработанная таким способом будет заканчиваться в уникальной адресной позиции, которую можно брать в качестве кода этой словоформы. Более того, таким же кодом можно кодировать регулярные словосочетания. И тогда возникает вопрос, а не будет ли такая кодировка с длиной слов равной адресу компактнее стандартной? Я уверен, что таки будет, т.к. иероглифическая запись короче алфавитной

Как видите, все не так

Давайте попозже

Наименьшее число -  это минус бесконечность...

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

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

Ну просто для работы Амальгамы потребуются суперкомпьютеры, а так ничего.

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

Чего тут интересного? Всё по теории: на 3 двоичных знака уже 14 байтовых адресов, на 8 двоичных знаков (1 байт) нужно будет 510 байтовых адресов. Всё как я описывал.

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

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

Нет, не вижу.