Pull to refresh

Comments 10

Само изложение текста крайне непонятное. Порой создается впечатление что это ИИ сгенерировал.

Я все ждал когда кто-то это прокомментирует. Меня не покидало ощущение, что это какой-то сгенерированный текст, но я допустил что это что-то сверх моего понимания. О чем тут вообще речь?

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

Если это не ИИ-генерация, то написано каким-то излишне сложным языком. Вот даже ваш комментарий:

Манипулируя различными точками входа в структуру 

что такое "точка входа в структуру"? Более 20 лет пользуюсь структурами, и никаких "точек входа" у них не встречал:) Сишная структура - одна из простейших базовых вещей в программировании вообще, у нее есть только поля.

struct Foo {
  int n;
  float x, y;
  char name[64];
};

Где здесь "точки входа"?

И на такое натыкаешься в каждом предложении статьи.

Hidden text
struct node {
  ui64 *somePtr;
}

struct point {
  int value;
}

struct altWay {
  ui64 *altPtr;
}

node.somePtr = malloc(sizeof(point));
altWay.altPtr = node.somePtr;

Очень удобно, когда необходимые вещи разложены в шаговой доступности, в нужной последовательности, тематически сгруппированы. Как на кухне, или еще лучше на складе. Гораздо сложнее, когда одни и теже сущности должны присутствовать одновременно в разных группах, разных последовательностях, но непременно в шаговой доступности. На складе так не сделать, если нет в кармане мини телепортатора. Нажал на кнопку, нужная вещь возникла перед тобой.

Допустим в условных процедурах необходимо произвести обработку неких данных. Проще всего обратиться напрямую к этим данным. Но если эти данные в огромной куче из десятков мегабайт, либо беспредельно большого количества отдельных элементов. В одной процедуре это данные, касающиеся одной группы, в другой касающейся другой группы. Сами данные одновременно относятся к смежным группам. Копировать их глупо, дублировать некорректно. Но выход есть, обращаться к эталонным данным из структуры указателей. Таким образом в один и тот же пункт назначения я могу попасть из разных точек. Тоже самое, что доехать до дома по пр. Ленина или Кирова, на выбор.

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

В примере Вы показали два указателя на одни и те же данные. При чем тут "шаговая доступность"? Доступность осуществляется через указатель. Текст описания вне моего понимания, попробуйте написать простыми словами без аналогий с навигаторами.

Ну хорошо, в С++ для этого применяют умные указатели. unique_ptr, shared_ptr, weak_ptr. Это вы имеете в виду?

Не совсем. Функционал умных указателей считает ссылки и производит автоудаление. Это другое. Я реализовал механику, при которой указатели организованы таким образом, что они многократно способны указывать на одни и те же данные, но в составе разных структур.

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

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

Конечно такой функционал придуман не впервые в истории. Конечно такое уже есть в разных вариациях и это очередная. Но здесь есть свои особенности. Абстрактность, малое количество ограничений, высокая степень усложнения структуры в тех случаях, когда это действительно необходимо. Я в статье описал пример загрузки в такую дифференциальную сеть формальной системы из своей стековой машины. Эта формальная система на первом уровне фильтрует поток символов на отрезки - токены. На втором уровне выдает из токенов инструкции. Поток это скрипт на синтаксисе классического С. Сколько понадобится различных if/else, а также сравнений, чтобы реализовать такой парсинг и сборку инструкций? Я выкинул их все. Просто загружаю в дифференциальную сеть символ из потока, потом след., потом след. Сеть мне выдает токен. Загружаю токен, она мне выдает связанную инструкцию. Итого продвигаюсь пошагово по скрипту, загружаю порционно данные, получаю порционно связанные данные. Вот и вся механика.

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

Указатели и так способны указывать на одни и те же данные в составе разных структур.

Создаем множество с помощью многократных вызовов malloc, выделяем нужные диапазоны для минимальных кусков данных и начинаем вносить. Имя - Сильвестр, фамилия - Шварценшницель,

Как мы отличим имя от фамилии? Получается, что у каждого кусочка данных должен быть еще и тег, описывающий что именно в нем хранится. Причем не языковой тип данных (строка, int, float), а смысловой (имя, фамилия, возраст...). Ну допустим, в С++ это можно сделать как множество вариантов (set<variant<>>). Вместо множества может быть любая другая структура - вектор, список и т.п. Вместо варианта - сделанное вручную тегированное объединение.

Создаем точку нуля

Что такое "точка нуля"? Это уже какая-то чисто ваша терминология.

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

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

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

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

Sign up to leave a comment.

Articles