На самом деле это было давно и не правда 😉 То есть я конечно ничего выдающегося не создал, но примерно с 2002 года с удовольствием занимался обдумыванием и разработкой базы данных, способной по моему мнению стать основой для ИИ. Ниже представлен дневник этих изысканий, в котором излагается как ход разработки и экспериментов, так и просто оторванный от реальности поток сознания и фантазий на тему. Причем на этой волне я несколько раз создавал и переписывал с нуля систему хранения, а также пробовал наполнять полезными для себя данными и пользоваться этим. В итоге все это со временем заглохло.
24.08.2002 Начало работы над проектом.
Основная единица информации в базе данных — «понятие» — представляет собой уникальный идентификатор. Может иметь или не иметь одну либо несколько ассоциаций.
— Ассоциация — ссылка на другое понятие, содержит также коэффициент ассоциации, или степень ассоциации.Чаще всего это свойство является двусторонним, но коэффициент ассоциации с обоих сторон может различаться. Коэффициент принимает значения от 0 (слабая ассоциация) до 1 (сильная ассоциация). Кроме коэффициента, ассоциация включает в себя причину/источник/объяснение ассоциации, которое является ничем иным, как понятием(ссылка на понятие).
(субъект ассоциации — понятие которое содержит данную ассоциацию, объект ассоциации — понятие на которое ссылается данная ассоциация)
БАЗОВЫЕ ПОНЯТИЯ:
Представляют собой необходимый минимум для установления ассоциаций между понятиями.
1 — простая ассоциация. Обозначает простую связь с объектом ассоциации.
2 — ассоциация обобщения. Обобщающая связь с объектом ассоциации. При этом объект ассоциации находится иерархически выше.
3 — ассоциация детализации.Объект ассоциации находится иерархически ниже.
4 — ассоциация идентичности.
5 — ассоциация противоположности.
База динамична, в моменты бездействия запущен процесс, который ищет и устанавливает новые ассоциации, подкрепляет / ослабляет старые, обобщает и детализирует понятия, устраняет ненужную избыточность информации.
25.08.2002 База данных создается на основе ИБ (временно, т.к. быстродействие такой БД после накопления определенного количества информации сильно снизится). Для обращения к базе данных в проект добавлен модуль BD, в котором будут расположены все процедуры для работы с базой данных.Взаимодействие с «внешним» миром осуществляется через модуль IO (InputOut).
Модуль IO оперирует такими данными, как «Ощущение». Одинаковые ощущения связываются с одинаковыми понятиями.Для понятий ощущения задействуем отрицательную область значений идентификатора. т.е. входной/выходной поток будет собой представлять символы в UNICODE со знаком «-«
Резервируем для этого диапазон — 1..65536
Обмен информацией будет осуществляться по так называемым каналам ввода / вывода.
Каждый такой канал будет соответствовать одному определенному источнику / приемнику информации.Таким образом например для клиента «Администратор» будет открываться все время один и тот же канал, выделенный для общения непосредственно с ним. т.е. таким образом будет производится идентификация объекта общения.Кроме того можно будет одновременно задействовать разные каналы для обмена с разными источниками информации, не мешая друг другу.
Модуль IO будет иметь непосредственный доступ к БД, и сможет заносить туда поступающую информацию независимо от остальных модулей. Для непосредственного низкоуровневого взаимодействия с БД создан модуль BD0, который будет собой представлять интерфейс для взаимодействия с БД. Это сделано для упрощения замены ядра БД с интербейза на любое другое.
Определил ассоциацию в модуле BD0:
I_AS = record // ассоциация
ID_AS: integer; // идентификатор ассоциации (0 — ассоциация еще не создана)
Value: smallint; // величина ассоциативной связи
ID_PN: integer; // понятие которому принадлежит ассоциативная связь (субъект ассоциации) (0 — понятие еще не создано)
ID_PN_DST: integer; // понятие с которым установлена данная ассоциативная связь
ID_PN_AS: integer; // тип/вид ассоциации.
end;
Создаваться в явном виде будут лишь ассоциации.Если понятия, которому принадлежит данная ассоциация не существует, то оно будет создано автоматически. Признаком того что понятие не существует будет являться 0 в качестве идентификатора понятия.
В BD0 добавлена процедура BD0_NewAssociations(List: TList) которая добавляет в БД новые ассоциативные связи соответственно списку.Список — записи типа I_AS.
Весь список добавляется в одной транзакции.Если понятие, которому принадлежит создаваемая ассоциативная связь не существует, то создается новое понятие. Во время одного вызова данной процедуры может быть создано не более одного нового понятия.
Добавлена процедура:
function BD0_GetPNAS(ID_PN: integer; var List: TList): integer; // нахождение всех понятий, с которыми данное понятие установило ассоциации
// Возвращает список List всех ассоциаций I_AS и количество элементов в списке на выходе
Ввел список зарезервированных понятий(те которые имеют отрицательное значение идентификатора).
65536 — для символов UNICODE, из них 256 управляющих(реально пока всего 4 управляющих).
65536 — для каналов ввода вывода.Итого 32768 каналов(располагаются / используются и резервируются попарно).
Еще нужно придумать как реализовать ощущение времени, точности до секунды будет скорее всего достаточно.Начал разрабатывать блок IO и понял что сначала все же придется реализовать ощущение времени.Долго думал, не так то это и просто…
Пришлось добавить еще некоторое количество зарезервированных понятий — 60 для секунд, 60 для минут, 24 для часов, 31 для дней, 12 для месяцев, 10 для годов, 10 для десятилетий, 10 для столетий и 10 для тысячелетий.Диапазон воспринимаемых значений получился от 0 до 9999 года.Еще зарезервировано 2 понятия для високосного и не високосного года. Все остальные значения эта штука понять не сможет.
Добавлены понятия для ассоциации заданного понятия с некоторым моментом времени, а также обратной ассоциации:
— момент времени.Включает в себя / обобщает / детализируется на такие понятия:
Нижеприведенные понятия применяются для связывания понятия конкретного момента времени, заданного одной, либо несколькими частицами с понятием частицы времени из диапазона FFFD0000..FFFD00EB.
— полное значение года включает в себя / обобщает / детализируется на такие понятия:
— значение тысячелетия
— значение столетия
— значение десятилетия
— значение года
— значение типа года([не]високосный)
— полное значение дня года включает в себя / обобщает / детализируется на такие понятия:
— значение месяца
— значение дня месяца
— значение дня недели
— полное значение времени дня включает в себя / обобщает / детализируется на такие понятия:
— значение часа
— значение минуты
— значение секунды
— «этому значению времени соответствует»(понятие применяется для связывания значения частицы времени (FFFD0000..FFFD00EB) и понятия конкретного момента времени, заданного одной либо несколькими частицами времени)
Итого служба ощущения времени отожрала зарезервировала под себя 256 понятий. Служба ощущения времени вынесена в модуль DateTime, также туда занесены все константы понятий, необходимые для функционирования данной службы.
Список базовых понятий уже стал настолько большим, что пришлось его вынести в отдельный файл проекта Default.txt
26.08.2002 Предполагается реализовать механизм сокрытия работы устройств ввода-вывода и службы ощущения времени — HideCall. Он будет анализировать все обращения к памяти и так называемые «мысли». т.е. проще говоря для ввода-вывода некоторой информации ИИ лишь необходимо об этом «подумать», т.е. создать понятие приема/передачи необходимой информации установив при этом ассоциацию с ощущением/понятием ввода-вывода. Ввод поступающей по открытому информационному каналу информации будет осуществляться модулем IO непосредственно в память, автоматически устанавливая необходимые ассоциации с источником информации, предыдущей порцией информации полученной по этому же каналу, а также временем получения этой информации.В этом смысле служба времени аналогична некоторому «имплантанту» при помощи которого программа узнает текущее время, она не знает как она это делает, она просто знает его и все…
Точно также как и мы не знаем как мы видим, мы просто видим. Кстати этот ИИ придется обучать числам и счету с самого нуля, в том числе и математическим действиям, например научить считать в столбик… глупо вроде как то: )комп, и вдруг на тебе — считает тормозно и в столбик!!!
Но лично я не вижу никакого иного способа сделать это, хотя все же два варианта имеется. Мы например когда хотим быстро что — либо вычислить берем калькулятор, вот и ИИ тоже для этих целей можно будет дать виртуальный калькулятор, зарезервировав к примеру под это один из каналов ввода / вывода и обучив ИИ пользоваться им. Все равно счет пойдет заметно быстрее, ну на худой конец можно поступить точно также как и с службой времени, создать к примеру службу вычислений и подключить точно также к определенным «нервам». Если возникнет необходимость что-либо вычислить то ИИ будет достаточно только подумать об этом и он уже будет знать ответ. Но вообще задача и без калькуляторов у меня непростая, так что пока нафик, нужно будет — посчитает и в столбик, ну вобщем это идеи на будущее.
Служба времени уже умеет создавать понятие текущего момента времени, на одно такое понятие в текущей реализации уходит 22 ассоциации каждая из которых занимает в памяти по 18 байт, получается 18 * 22 = 396 байт на ассоциации и 4 на само понятие, итого 400 байт.Такими темпами базы в 1 Гиг хватит всего на 50 — 55 миллионов связей, а если учесть еще и необходимое пространство для индексов, то и на 35 — 40.
На практике база с 10000 связей заняла 1162240 байт, т.е. по 116 байт на запись, тогда получается что 1 Гига хватит примерно на 9.000.000 связей, короче интербейз для этого не годится, придется потом писать свой движок.
Добавлен модуль оптимизации Optim. Будет заниматься оптимизацией связей, устранением избыточности связей. Позволит ощутимо снизить занимаемый базой объем и временные затраты на поиск необходимых понятий. Выделение и слияние идентичных понятий, удаление понятий с которыми не установлено ни одной ассоциации(потерянные понятия).Как минимум модуль будет получать управление в моменты бездействия системы, а также предположительно ему будут выделяться небольшие кванты времени при добавлении новых связей, чтобы при возможности их тут — же оптимизировать.
27.08.2002 Логически правильным было бы организовать еще одно базовое обобщающее понятие — «ассоциация», от которого уже произойдут все остальные понятия. Это поможет четко установить возможность установления ассоциативной связи при помощи заданного понятия.
Еще понадобится при помощи набора понятий устанавливать правила ассоциирования объектов, что даст возможность ИИ самостоятельно создавать собственные виды ассоциативных связей и использовать их.
29.08.2002 Для нормальной работы службы времени вводим такое понятие, как текущий момент времени(FFFD 00 FD), т.е. настоящее время.
Применяется для создания от него ассоциации на понятие включающее в себя значения всех составляющих значения текущего времени, т.е. является источником ассоциации.Служба времени получает управление из модуля HideCall для создания текущего понятия времени и создание на него ассоциации от понятия(FFFD 00 FD). Короче говоря как только запрашивается список ассоциаций от понятия FFFD 00 FD служба времени создает понятие текущего момента времени с включенным в него значением всех составляющих времени и создает ассоциацию от понятия FFFD 00 FD к только что созданному понятию. При этом предыдущая ассоциация от понятия FFFD 00 FD удаляются (перед этим проверяется заюзано ли кем нибудь понятие, на которое она указывает и если нет, то оно тоже удаляется), оставив лишь только что созданную. Затем управление возвращается модулю BD0, который уже выдает запрошенный список ассоциаций, включив в него также и только что созданную ассоциацию.Ну а далее уже можно создать двустороннюю ассоциацию с этим понятием от любого необходимого понятия.
31.08.2002 Организована система скрытых вызовов.Созданы следующие вызовы:
procedure HC_BeforeNewAs(List: TList) — Вызывается перед созданием серии новых ассоциаций
procedure HC_AfterNewAs(List: TList) — Вызывается после создания серии новых ассоциаций
procedure HC_BeforeGetAs(PN: integer; List: TList) — Вызывается перед запросом списка ассоциаций данного понятия
procedure HC_AfterGetAs(PN: integer; List: TList) — Вызывается после запроса списка данного понятия
Внутри этих процедур будут размещаться тела обработчиков вызовов.
Похоже процесс усвоения информации будет очень напоминать растворение, т.е.получив некоторый информационный блок ИИ не будет его хранить в исходном виде а будет как — бы усваивать его, растворяя в собственной памяти, частицы информации этого блока будут обретать связи с уже существующими понятиями и сами будут трансформированы в понятия.Сам процесс полного усвоения информации может быть довольно ресурсоемок а поэтому скорей всего разбит на два этапа.На первом этапе сразу после получения блока будут установлены самые очевидные ассоциации с информацией, содержащейся в нем. При дальнейшем анализе полученной информации глубина ассоциаций, на которую будет производится сканирование памяти будет возрастать до некоторого значения(во время этого процесса, при нахождении совпадений, закономерностей и других связей будут устанавливаться ассоциации с уже существующими и усвоенными понятиями), после достижения некоторой глубины сканирования(скорей всего при помощи рекурсии)блок информации можно считать усвоенным.После этого он уже не является отдельным блоком информации, и не имеет четких границ в памяти.
04.09.2002 Добавлены функции BD0_NA(List: TList) и BD0_GP(ID_PN: integer; var List: TList): integer; это аналоги BD0_GetPNAS и BD0_NewAssociations, но перед и после их выполнения управление передается в модуль HideCall для обработки базовых ассоциаций.
Оптимизирована работа BD0_NewAssociations и исправлена логическая ошибка.
Ковыряться в базе вручную стало довольно не удобно, придется соорудить удобные средства отладки и мониторинга содержимого памяти.
Созданы процедуры для чтения / изменения примечаний идентификаторов:
procedure BD0_SetNote(ID: Integer; S: string);
function BD0_GetNote(ID: Integer): string;
07.09.2002 Думаю необходимо реализовать единый механизм ввода / вывода информации, который бы позволил осуществить взаимодействие с любыми внешними устройствами. С реализацией службы ощущения времени я похоже несколько поспешил. На начальном этапе она не нужна и лишь усложняет дело.
08.09.2002 Решил отбросить не только службу ощущения времени, но и упростить ввод / вывод информации. Он будет происходить всего через один канал. Кроме того прежняя схема ввода / вывода, где для каждого символа отводится по отдельному «ощущению» является излишне избыточной, т.к.в любой момент времени на входе одновременно может «ощущаться» лишь один символ.Короче говоря пока количество ощущений урезается до восьми, т.е. максимально 256 вариантов ощущений. Кроме того из области базовых понятий будут исключены все понятия службы ощущения времени.
09.09.2002 Пересмотрена схема базовых понятий и ощущений(заметно упрощена):
0000 00XX — Диапазон ощущений ввода / вывода.
0000 0100 — связывает конкретное понятие с понятием ощущения.
0000 0101 — понятие ввода информации. При поступлении ощущения m создается новое понятие n, M ассоциируется с N посредством 0000 0101. Обратная ассоциация создается посредством 0000 0100.
Для базовых понятий зарезервирована область идентификаторов вплоть до 0000 01 FF.
Приведенный выше список — абсолютный минимум, который позволит системе самостоятельно воспринимать и запоминать информацию, но пока не позволит ее анализировать. В принципе возможен и вывод информации, но на данном этапе эта функция не имеет смысла. В диапазоне ощущений ввода / вывода определим ощущения начала / конца строки.
0000 0001 — ощущение начала сообщения.
0000 0002 — ощущение окончания сообщения.
При вводе символа(ощущения)»O» образуется новое понятие «New». При этом они связываются двумя ассоциациями по схеме:
O — 00000101 — > New
New — 00000100 — > O
Написана procedure IO_Input(Str: string); (прием строки символов с внешнего устройства в память).Процедура протестирована и работает нормально, но такая система не дает возможности установить последовательность приема ощущений и при приеме более одного сообщения (последовательности ощущений) невозможно опознать какие символы какому сообщения принадлежат.
10.09.2002 Добавлены два новых вида ассоциаций:
0000 0102 — указывает на следующее принятое ощущение после данного.
0000 0103 — указывает на ощущение принятое перед данным ощущением.
Отменил использование символов начала и конца строки как излишне избыточных. Задействовал два вышеупомянутых вида ассоциаций. Теперь можно легко по отдельно взятому символу найти следующий или предыдущий символ, или всю цепочку символов. Определить последовательность поступления цепочек символов пока еще не возможно. Процедура снова отлажена.
12.09.2002 Добавлены ассоциации:
0000 0104 — указывает на принадлежность данного понятия к понятию экземпляра принятой цепочки символов.
0000 0105 — указывает на то что данному понятию экземпляра принятой цепочки символов принадлежит целевое понятие.
Позволяют оперировать понятиями экземпляра принятой цепочки символов. Уже используется при приеме цепочки символов.
Соответственно логично будет добавить следующие ассоциации:
0000 0106 — указывает на следующий экземпляр цепочки принятых символов.
0000 0107 — указывает на предыдущий экземпляр цепочки принятых символов.
Для их использования нужно знать идентификатор понятия экземпляра принятой цепочки символов. Как вариант можно будет создать понятие последней принятой цепочки символов, которое всегда будет указывать на него.
14.09.2002 Оптимизация кода, повышение его читаемости, проверка. При добавлении новых ассоциаций списки больше не используются, что гораздо удобнее чем раньше.
21.09.2002 Начат блок графического представления памяти.
06.10.2002 Думаю немного изменить систему восприятия. Пока она дискретна, но должна стать непрерывной, т.е. вместо входных цепочек символов будет один непрерывный поток, который система уже сама должна будет разделять на цепочки, фразы и слова.Также существенные изменения нужны блоку оптимизации, он будет полностью реализован в памяти устройства, что даст большую гибкость для изменения и дополнения правил оптимизации.Но скорей всего это позже, так как пока не совсем ясно как наилучшим образом организовать механизм восприятия и воздействия блока оптимизации изнутри.
09.10.2002 Немного доработан блок графического представления. Поскольку система воспринимает непрерывный поток символов, то понятие цепочки символов пока не нужно.
16.10.2002 Исключены все понятия «цепочек» символов.
Добавлено новое базовое понятие:
0000 0104 — понятие последнего принятого ощущения
Еще как минимум понадобится понятие ассоциации… По моему этому понятию ничто не мешает исполнять и роль понятия и роль ассоциации, но скорей всего все же лучше придерживаться принятой концепции и вести еще отдельно ассоциацию:
0000 0105 — указывает на экземпляр понятия последнего принятого ощущения.
добавлена процедура удаления ассоциации по ее номеру:
procedure BD0_DelAS(ID_AS: integer);
Потихоньку начала складываться система условных обозначений для записи алгоритмов:
<понятие-1> — <ассоциация> -> <понятие-2> — Схематическое обозначение ассоциативной связи.
CREATE_AS (ассоциация) — Создать ассоциацию
DELETE (ассоциация) — Удаление ассоциации
DST (ассоциация) — Взять идентификатор приемника ассоциации
VARIABLE := -присвоить переменной значение
xxxxxxxx — значение не определено
Алгоритм восприятия нового ощущения выглядит след.Образом:
Вход: O — принятое ощущение
New — текущее образуемое понятие
begin
CREATE_AS(O — -00000101 — > New)
CREATE_AS(New — -00000100 — > O)
LAST := DST(00000104 — -00000105 — > xxxxxxxx)
if LAST <> 0 then begin
CREATE_AS(New — -00000102 — > LAST)
CREATE_AS(LAST — -00000103 — > New)
end
DELETE(00000104 — -00000105 — > xxxxxxxx)
CREATE_AS(00000104 — -00000105 — > New)
end
17.10.2002 Первая задача выполнена. Восприятие работает. На данном этапе система способна тупо воспринимать и запоминать входные ощущения. Правда на основе ИБ это очень тормозно… Тестовый текст, размером 13000 символов система воспринимала около 20 минут.После чего в БД оказалось около 13000 понятий, 52000 ассоциаций, а сама база заняла 6680000 байт.Короче на мегабайтном куске текста база вырастет на 500 метров…
23.10.2002 Дописан модуль графического представления памяти.Картинка смотрится довольно кошмарно…красиво конечно, но практического интереса не представляет.
25.10.2002 Первый из процессов обработки будет находить совпадения и логически связывать совпадающие группы понятий, тем самым устраняя избыточность информации.
07.11.2002 Начат модуль «Constant.pas», в котором будут объявлены все константы и который будет содержать процедуру инициализации базы, и создание всех начальных базовых понятий и ассоциаций.
Добавлено новое базовое понятие:
0000 0106 — базовое понятие ассоциации, родитель всех остальных видов ассоциаций.
Создаем как прямую, так и обратную связь. Хотя насчет обратной связи еще толком не ясно, понадобится ли она.Но согласно принятой мной ранее концепции лучше все же всегда создавать как прямую, так и обратную связь.
Теперь можно будет легко выяснить, является ли исследуемый объект ассоциацией, т.е. потомком от данного понятия.
Почти закончил чтение ветки о ИИ на ixbt.com.К сожалению ничего ценного там не обнаружил.Основные два направления — реляционные БД и нейронные сети.
Ближе всех к моему проекту похоже Vladymir Rybinkin но у него немного другие задачи, хотя основная суть БД гораздо ближе к моей реализации, чем все остальные.
Мне пока все еще не удается четко сформулировать основные принципы обработки информации в моей БД, хотя чувствуется, что топчусь где — то рядом: )
Процессы обработки по идее должны носить лавинообразный характер, т.к. каждое изменение БД будет порождать новые процессы обработки информации, это должно происходить автоматически, т.е. на подсознательном, не контроллируемом уровне системы.
10.11.2002 Берем текущее, исследуемое понятие составляем список объектов, ассоциированых с ним перебираем этот список, пока не удастся оптимизировать берем очередное понятие из списка и составляем список объектов, на которое оно указывает, используя ту — же ассоциацию, что и на первоначальное понятие.
Сравниваем ассоциации исследуемого понятия с ассоциациями найденного.
Вот тут — то я и застрял, легко сказать «сравниваем»… Нет, не так.Попробуем зайти с другого конца.Раз не получается у меня найти модель «универсального» оптимизатора, который мог бы работать с любыми данными, тогда попробуем соорудить класс понятий, который бы представлял собой множество моделей данных, описывая их структуру и методы представления в виде понятий, т.е.это и будут метаданные. Эти метаданные должны описывать структуру, зависимости и все связи между понятиями, они являются теми — же данными но уже как бы осмысленными и понятыми, разобранными на составляющие и объединенные с уже известным «миропредставлением».Все остальные — просто потенциальные данные, которые хоть и имеют связи с метаданными, но не осознаны / не поняты / не обработаны / не представляют информационной ценности, но потенциально из них могут быть порождены метаданные.Данные, могут не перейти в метаданные по нескольким причинам:
-
Недостаток информации для обработки / понимания.
-
Оставленные для будущей, более глубокой обработки, при поступлении производится только поверхностная обработка и если ее не достаточно, то требуется увеличить глубину обработки.
-
Информация не имеет смысла / ошибочна / представляет собой просто шум.
Вобщем — то третий пункт это почти то же что и первый, ведь при недостатке информации о структуре данных они с виду могут представиться ошибочными или просто шумом, не несущим смысловой нагрузки.
Итак, вся область понятий будет поделена на метаданные и просто данные.
11.11.2002 Как бы мне этого не хотелось, но по моему никакие универсальные алгоритмы обработки данных не могут сами созать «правильную» начальную структуру данных, которая смогла бы в последствии сама «дрейфовать» в нужном направлении.
Процедура инициализации БД — CreateBase, которая придает БД первоначальную стартовую структуру.
Вначале создадим базовые ассоциации, которые собственно и формируют множество ассоциаций.
// Создаем как прямую, так и обратную связь
BD0_NA(pn_association, pn_svz, pn_association);
BD0_NA(pn_svz, pn_association, pn_association);
BD0_NA(pn_association, pn_in, pn_association);
BD0_NA(pn_in, pn_association, pn_association);
BD0_NA(pn_association, pn_prev_o, pn_association);
BD0_NA(pn_prev_o, pn_association, pn_association);
BD0_NA(pn_association, pn_next_o, pn_association);
BD0_NA(pn_next_o, pn_association, pn_association);
BD0_NA(pn_association, pn_last_oa, pn_association);
BD0_NA(pn_last_oa, pn_association, pn_association);
Далее нужно сформировать все основные множества:
(реально это пока еще только в планах) {
— множество всех входных понятий
— множество всех печатных символов
— множество символов-разделителей
— множество спец-символов
— множество символов русского алфавита
— множество символов английского алфавита
— множество символов-цифр
— множество символов нижнего регистра
— множество символов верхнего регистра
— каждый символ нижнего регистра должен быть противопоставлен соотв. символам верхнего регистра, что должно соответствовать след. уровню абстракции.
Как ни крути нужны логические понятия
Требуется введение некоторых понятий высокого уровня абстракции:
— понятие множества
— понятие противоположности
— понятие последовательности (не след. или пред. а общее)
— понятие следующего элемента последовательности
— понятие предыдущего элемента последовательности
— понятие начало последовательности
— понятие конец последовательности
* Вообще-то рано или поздно потребуется указание последовательности
следования символов в алфавите русского и английского, с указанием
начала и конца алфавитной последовательности.
** Еще в более отдаленном будущем следует рассмотреть введение понятия транскрибции, т.е. соответствие букв и буквосочетаний звукам. Как русского, так и английского алфавита. (в дальнейшем введение таких понятий может открыть очень интересные возможности)
Добавлена процедура очистки БД BD0_Clear
Немного изменен алгоритм работы процедуры установки примечания.Если объект не существует, то он будет создан.
Объекты, посредством которых осуществлялся ввод информации в систему ранее я называл входными ощущениями или входными понятиями, эти термины несколько неправильно звучат, поэтому далее буду именовать их интерфейсными, т.к. это точнее отражает их смысл а кроме того посредством них возможен не только ввод но и вывод информации.
В инициализацию добавлено формирование всех интерфейсных понятий диапазона $00..$FF
Самое непонятное и страшное пока это отладка создаваемой структуры и нахождение логических ошибок и несоответствий, а тем более исправление. Просто удалять понятия нельзя, требуется нахождение всех связей, кроме того любые изменения затронут соседние связанные элементы структуры и пока не понятно как отслеживать и оценивать эти изменения.
Назрела необходимость введения понятия множества:
pn_set $00000107; // базовое понятие множества
pn_set_in $00000108; // указывает на принадлежность данного понятия к множеству
pn_set_pn $00000109; // указывает на понятие, входящее в данное множество
А также давно пора ввести общие понятия, указывающие на экземпляр понятия (класса)и понятие экземпляра, т.е.указывающее на класс понятия.
pn_uin $0000010A; // Указывает на экземпляр данного понятия
pn_base $0000010B; // Указывает на базовое понятие, экземпляром которого является данное понятие
Понятие созданное таким методом наследует все свойства «родителя»
Уже скоро и тут запутаюсь, пора принять какие — то общие термины, лучше всего наверное будет принять термин «класс», который будет собственно тем, что раньше называлось «понятие», а еще будет такой термин как экземпляр класса, и обозначать это будет почти то же самое, что и в других языках программирования.
Создано множество интерфейсных понятий с прямыми и обр. ассоциациями.
13.11.2002 Выкинул нафиг блок графического представления… пасовских файлов в проекте осталось чуть более 13 кил.
В инициализацию добавлено множества символов Русского и Английского алфавита. Некоторая нормализация остального кода.
Возникла идея не писать блок инициализации на паскале, а разработать специализированный скрипт — язык для этого, что было бы удобней, т.к. предполагается закладывать не маленький объем инициализационной информации. Даже потом можно будет сделать функцию экспорта всей базы в скрипт.А сам скрипт хотелось бы чтобы умел не только создавать понятия и связи, но и модифицировать созданные ранее.
14.11.2002
Файл инициализации будет иметь примерно такой формат:
‘:’ — символ разделитель полей
первое поле всегда указывает на тип строки
‘#’ — комментарий
‘+’ — создается новое понятие, идентификатор можно не указывать
+ : [00000000: ]pn_name: краткое описание
‘-‘ — создается ассоциация, и обратная ассоциация если нужно
— : pn1: as1: pn2[: as2]
15.11.2002
Думал над вопросом как правильно оперировать множествами.
Пока надумал вот что:
-
Предком подмножества всегда должно быть множество (ассоциация устанавливается посредством стандартных pn_base, pn_uin). В корне всех множеств находится базовое понятие множества всех множеств pn_set.
-
Новые понятия в множество включаются при помощи ассоциаций pn_set_in, pn_set_pn.
-
В подмножество могут входить только те понятия, которые входят в множество предка подмножества.
-
Множество может включать в себя другие множества.
Пункт 3 пока еще под вопросом, возможно это только лишнее ограничение.
Добавлено множество десятичных цифр pn_set_dec.
16.11.2002 Похоже со множествами английских и русских символов я поспешил. Вначале неплохо бы объединить попарно символы верхнего и нижнего регистров.
Количество паскалевского текста подозрительно быстро начало расти… Я уж думаю лучше бы вносить все новые понятия прямо в БД, хорошо документируя этот процесс, делая бэкап и сохраняя их вместе с документацией, существующей на момент бекапа, чтобы можно было вернуться на несколько шагов назад.
Т.е.Лучше всего заняться программированием непосредственно БД, для чего кроме уже существующего просмотра необходимо создать еще и утилиту редактирования БД, которая умела бы работать с мнемоническими кодами ранее определенных понятий, а еще лучше чтобы оно умело исполнять что — то вроде скрипта…хотя в общем второе не обязательно, дальше должно вроде бы пойти уменьшение однородности понятий, таких как символы алфавитов.
Вобщем скрипт пока будет функционировать по правилам от 14.11.2002 с некоторыми упрощениями.
-
Все определения констант будут вынесены в отдельный файл const.txt
-
Основной скрипт будет находится в init.txt, формат записей примерно такой:
pn1: < note > -определение нового понятия, при этом если мнемоническое имя понятия отсутствует в константах, то создается новое понятие.
pn1: pn2: as1 — определение ассоциации pn1 — as1 — > pn2
pn1: pn2: as1: as2 — определение ассоциации pn1 — as1 — > pn2 и обратной ассоциации as2
Блок чтения констант вроде заработал. Даже уже сформированы основные константы интерфейсных понятий (с префиксом ifc_ после которого следует сам символ понятия).
Блок создания понятий и ассоциаций тоже вроде как работает.
Между собой проассоциированы большие и маленькие буквы русского алфавита, т.е.созданы множества букв А, которое включает в себя большую и маленькую букву А и т.д.эти множества получили префикс rus_А, где А — русская буква(включая твердый и мягкий знак). То же самое сделано и с символами английского алфавита, префикс — eng.
17.11.2002 Создано множество русских букв rus, включающее в себя буквы рус.алфавита. Аналогично создано множество английских букв.
понятия pn_next_o, pn_prev_o успрощены до pn_next, pn_prev т.е.стали базовыми понятиями.
Ввел понятие first, last — первый элемент последний элемент. По сути это является указателем на противоположные элементы последовательности либо множества, так что вполне возможно, что лучше всего их будет объединить под одним множеством — противоположность.
Появились некоторые сомнения в правильности базовой концепции принятой мной модели БД. Нужно подумать возможно ли еще упростить модель, и обойтись всего одним типом связи на все случаи. Раньше я был уверен в невозможности такого, но сейчас появились некоторые свежие соображения.
24.11.2002 Мне так и не удалось толково сформулировать основы системы с единым типом связей, так что займусь пока тем, что есть.
Создано множество противоположных элементов prt, в которое входят понятия first и last.
Новое понятие as_protiv: Указывает на элемент, противоположный данному
При помощи этой ассоциации связаны понятия first и last а также pn_prev и pn_next
/Далее поток утопических мыслей в духе того как если бы система уже написана/
Вообще система в целом получилась довольно интересной. Она состоит из множества отдельных элементов, любой из которых сам по себе не содержит информации. В системе нет такого понятия как типы данных или данные вообще, здесь все совместимо со всем. Таким образом не существует проблемы несовместимости типов. В системе отсутствует такое понятие как формат данных, значит отпадает несовместимость форматов. В системе отсутствует какая либо адресация хранящихся знаний, значит нет опасений, что когда — нибудь разрядности адреса не хватит. Система не нуждается в индексации данных — все данные уже индексированы, т.е.не требуется перебирать множество элементов для поиска необходимого.Система не требует сжатия хранимых данных — информация уже сжата. А внутреннее виртуальное пространство ничем не ограничено. Система полностью абстрагирована от каких — либо носителей информации. Система в процессе работы не производит никаких манипуляций с большими объемами данных, этого не требуется. Невозможно сказать что эта информация хранится здесь, а та там, оно не отделимо от остальной части системы. Система не статична, она меняется в процессе получения новых данных, меняется сама структура системы в процессе восприятия информации, т.е. полученная информация меняет систему, она сама в состоянии изменить себя. Если произошло «восприятие» некоторой информации системой и система изменила свое состояние, то практически этот процесс не обратим, разве что путем полного сохранения системы до момента восприятия ключевой информации и восстановления впоследствии. Система меняет свое состояние только после получения данных, имеющих смысл, в пределах «понимания» этого смысла системой.Бессмысленные данные практически не должны изменять состояние системы и возможно со временем будут отброшены / «забыты», правда вряд ли в этом возникнет необходимость. Пока вообще не понятно нужен ли механизм забывания, разве что как предохранитель / защита от дураков, да и все равно в понятиях системы данные не имеющие смысла не занимают места внутри системы, т.е. конечно физически место занимается, но логическое пространство системы от этого совершенно не перегружается.Эта система «в себе», она не написана на каком — либо языке программирования, она на собственном, внутреннем языке. У системы не существует разрядности, или какого — либо диапазона, ограничивающего систему, а значит не может быть и никаких переполнений, исключений, ошибок…нечему переполняться. У системы нет «родной» системы счисления, подобно той, какая есть у процессора, т.е. не имеет значения в какой системе счисления будет происходить «обучение».
Вот думаю, как мне определять последовательность. Как определить след./пред. элемент последовательности ясно, но как лучше всего задать начало/конец? Во первых вся последовательность должна быть определена как некое понятие, т.е. это может быть просто множество элементов последовательности, или хотя бы множество начала и конца последовательности, тогда от общего понятия последовательности можно создать ассоциацию first на первый элемент и last — на последний, а от первого элемента уже next на след.и так далее.Аналогично от элемента last создается ассоциация prev на предыдущий элемент.
Определена последовательность букв в русском/английском алфавите
Определено множество символов — цифр «dec» а также их логическая последовательность
26.11.2002 Стандартный подход к информационным системам такой:
информация + алгоритм = информация. Я уже понял что даже такой, казалось бы высокий уровень абстракции для планируемой мной системы тоже низок, это остановка на полпути. Нужно достичь следующего:
информация + информация = информация. Т.е. это уже самый высокий уровень абстракции, при котором даже алгоритмы вырождаются в простую информацию, и эту информацию уже никоим образом нельзя назвать алгоритмом.Вся информация из пассивной становится полностью активной.В новой системе информация сможет взаимодействовать с другой информацией напрямую.
Одно из основ системы — понятие множества «pn_set».Множество, это всегда «любой из». Сейчас мне понадобилось схожее понятие, но немного с другим смыслом, не «один из числа элементов», а «все элементы», т.е. понятие множества как бы объединяло элементы по принципу or а теперь мне нужно понятие, объединяющее элементы по принципу and. Это даст возможность ввести такие понятия, как например «последовательность» или «конечная последовательность». Т.е. в которые будут входить указатели first, last, next, prev, что даст возможность отнести к понятию «последовательность» все понятия, которые имеют данный набор указателей. Хотя… может быть стоит сделать немного по другому. Например просто создать множество «последовательность» и внести в него все понятия — последовательности, тогда теоретически у системы появляется возможность проанализировав множество последовательностей выявить общие признаки всех последовательностей и самостоятельно создать обобщенное понятие последовательности. Этот вариант мне нравится больше, но здесь необходимо еще подумать как заставить автоматически «верифицировать» и пополнять признаки вхождения заданного понятия в множество, как хранить этот набор признаков, как организовать набор правил и исключений для признаков.
28.11.2002 Добавлена следующая группа понятий:
pn_set_and: 00000114: Базовое понятие набора входящих в него понятий
as_set_and_in: 00000115: Указывает на принадлежность данного понятия к указанному набору
as_set_and_pn: 00000116: Указывает на понятие, входящее в данный набор.
Несмотря на то, что все вроде получается логично, мне кажется что принятый мной способ ассоциаций несет слишком большую информационную избыточность, из — за чего часто тяжело бывает решить какие именно ассоциации использовать для необходимых связей.Думаю здесь нужно будет упрощать, правда заметно это становится только сейчас. Т.е. поработав немного по существующим правилам я уже вижу что стоит поменять и упростить. Например принять что:
-
Связь всегда двусторонняя, т.е. это означает что с обоих концов имеется прямая ссылка(связь) на противоположный элемент.
-
Связь может быть восходящая и нисходящая, т.е. указатель на родителя или предка, и так как все связи двусторонние, то указание с одной стороны как на предка автоматически подразумевает, что обратная связь — указатель на родителя.
Таким образом при «чтении» информационной структуры основную информацию несет уже не тип связи, а целевой объект.
Вот пока и все… осталось только подумать, можно ли все что уже сделано реализовать при помощи новой модели, т.е. не слишком ли я упростил, иначе информации может оказаться слишком мало для существования смысловой информационной структуры.
Сделан полный бекап системы в архив «init021128_0.rar».
29.11.2002 Подумал насчет вчерашней модели. Не подходит. Получается недостаток информации. Так что модель пока остается прежней.
Появились некоторые соображения насчет процедуры «усвоения» данных. Универсальной методики не будет. Придется написать мета-алгоритм, который смог — бы на основе уже сформированных структур по их «аналогии» производить обработку остальных структур. Т.е. он должен будет выделить общие признаки (тип ассоциативных связей между уже обработанными данными), и по этим признакам выделить пригодные к преобразованию участки структуры. Т.е. вначале требуется некоторое обучение.
Еще думал над вариантом программирования методик обработки. Т.е. на специальном языке программистом определяется критерии и способ обработки. Этот метод не так гибок как предыдущий и для новых методов требует вмешательство программиста…
Но есть надежда что практически пригодных методик обработки окажется не так уж и много. Наконец третий вариант.Никакого алгоритма обработки данных нет вообще. Плохо но не фатально.Тогда анализ и обработка новых данных будет проходить при помощи программиста. Т.е. это будет просто новый вид программирования, что тоже не так уж и плохо.Но все же я уверен что удастся реализовать как минимум алгоритм номер два, а если это получится, то накопив несколько методик, возможно я увижу некоторые закономерности что даст мне возможность использовать первый вариант процедуры.
А пока продолжим набирать «критическую» массу данных; )
01.12.2002 Одно из понятий, требующих скорейшего определения — «последовательность», а также «конечная последовательность». Т.е. если между любыми элементами существует связь типа next, prev то это элементы последовательности. Нужно еще разделять общее понятие последовательности и понятие элемента последовательности.
Скорее всего правильнее будет организовать множество последовательностей, а затем, если рассматриваемое множество некоторых элементов является последовательностью — включаем это множество в множество последовательностей.
Что еще остается придумать, так это то, как собственно эти критерии хранить и модифицировать. При таком подходе обязательно время от времени будут попадаться последовательности не включенные в множество последовательностей, т.е. получается как бы система еще не «осознала» тот факт, что данное понятие тоже является последовательностью. И таких случаев будет очень много. Для таких случаев и нужны процессы, которые непрерывно бы «переваривали» информацию, а совсем в идеале сюда подошла бы концепция «агентов», т.е. активных составляющих.
Пока все равно придется ограничится процессами, дабы получить хоть какого — нибудь «тугодума»:) Тогда при простое этот процесс будет работать на полную мощность, т.е. получается что система как бы спит.
Новое понятие:
serial: 00000117: Множество последовательностей
В связи с вышеизложенными соображениями ликвидирована группа понятий, которая была добавлена 28.11.02 (Они как то не очень вписываются в общую архитектуру, и смотрится довольно «некрасиво»).
Теперь смотрим что из уже определенного входит в множество последовательностей:
serial: rus: pn_set_pn: pn_set_in
serial: eng: pn_set_pn: pn_set_in
serial: dec: pn_set_pn: pn_set_in
Еще не красиво у меня определяются множества:
например так — dec: pn_set: pn_base: pn_uin
Это не правильно. Если у меня имеется множество всех множеств — pn_set, то и для обозначения вхождения всех остальных множеств в это множество нужно пользоваться «pn_set_pn: pn_set_in» а не «pn_base: pn_uin».
Исправляем…
Таким образом «pn_base, pn_uin» пока нигде не заюзано. Нужно ли оно вообще, это еще не ясно, но подумать надо, может удастся обойтись и без этого. Все заметно упростилось и пока хорошо укладывается в существующую систему, а это уже хороший признак; )
Из нерешенных вопросов еще остается вопрос о весовых коэффициентах, не понятно нужны ли они вообще.
02.12.2002 Никак не могу определиться что делать дальше… Начинать понемногу определять слова, так этим можно годами заниматься.Лучше, если бы эти слова уже могли — бы восприниматься с устройства ввода, но как они тогда будут увязываться с внутренними понятиями? Предположительно можно ввести некоторый протокол для обмена данными, который включал бы в себя и некоторые управляющие сигналы, для прямого воздействия. Кроме того это создаст некоторое дополнительное «пространство» для дальнейшего «развития».Возможно стоит также подумать о «органах» осязания внешнего хранилища информации, которое было бы статично.
Значит все равно придется разрабатывать протокол обмена информацией. Вот над этим и стоит подумать.
08.12.2002 Чтобы научить систему «осязать» информацию из входного потока в любом случае необходим входной протокол. Похоже здесь больше всего подходит метод проектирования сверху вниз. Самой крупной единицей входного потока будет «фрейм». Фрейм — последовательность символов, ограниченная стартовым и стоповым символом. Система должна приступать к анализу информации лишь после того, как фрейм полностью получен.
ifc_fr_beg: 00000000: Символ начала фрейма
ifc_fr_end: 00000001: Символ конца фрейма
Поскольку сами старт / стоповые символы никакой инфы не несут, они не должны сохраняться.
16.12.2002 Долго размышлял достаточно ли принятой системы восприятия для функционирования, т.е. опять же существует ли некоторая критическая масса системы восприятия, достаточной для дальнейшего самостоятельного функционирования и саморазвития.Вывод — достаточно любой системы восприятия. Система восприятия не является узким местом или ограничением т.к. это легко компенсировать за счет оптимально разработанного протокола обмена данными. Т.е. абсолютный минимум — канал шириной в один бит.
19.12.2002 По моему обмен данными с внешним миром вообще не является первостепенной задачей на первых этапах. Т.е. пока нечего выводить и нечего вводить то и обмен данными не нужен, нет смысла т.к. система все равно не сможет никак обработать поступившие данные, не поймет их.
Я уже успел наплодить достаточно лишних и ненужных модулей системы, так что пора переписать все с нуля:) и кроме того выкинуть интербейз. Будем считать что это была система версии 0.01. Старыми останутся только блоки данных const.txt и init.txt, но я еще дополнительно хочу включить в них возможность инклуда, и вообще объединить их в одно а потом еще добавить возможность выгрузки БД в этом формате. Типа как бэкап в ИБ.
Начнем проектирование с собственно драйвера БД.
Прежде всего требования к самой базе данных:
— Не должно быть привязки к разрядности идентификаторов.
— За каждым идентификатором могут быть закреплены следующие данные:
-
Текстовое примечание (длина 0..255 символов)
-
неограниченное количество ссылок, каждая из которых содержит идентификатор ассоциации и целевой идентификатор.
Это собственно и все требования к структуре данных:) чем проще тем правильнее. Должны быть реализованы след.процедуры:
— procedure CreateID(ID: integer);
— procedure SetNote(ID: integer, Note: string);
— function GetNote(ID: integer): string;
— procedure AddAss(ID_SRC, ID_DST, ID_ASS: integer);
— procedure GetAss
Нужна индексная таблица идентификаторов.Подойдет обычный TList. Идентификатор должен оставаться неизменным на протяжении всего времени жизни БД, а значит идентификаторы из TList удалятся не будут, разве что обнуляться или добавляться. Создан модуль BD и класс TBD — база данных.
Добавлен метод TBD.Init;
Решил что проще всего будет сделать через TStringList. Где будут хранится примечания и ассоциации (побайтово).
Реализовано:
procedure Init;
procedure CreateID(ID: integer);
procedure SetNote(ID: integer; s: string);
function GetNote(ID: integer): string;
procedure AddAss(ID_SRC, ID_DST, ID_ASS: integer);
function GetAss(ID, AssNum: integer; var ID_DST, ID_ASS: integer): boolean;
function AssCount(ID: integer): integer;
Собственно все.Основной модуль БД готов.
Теперь попытаемся переделать старые процедуры для работы с этим новым модулем.
Добавлена процедура выгрузки базы в файл:
procedure Save(FileName: string);
Создается два файла. Первый с расширением.ai — сама база, второй.note — примечания
Перепись процедуры выполнения инициализационного скрипта оставлю на завтра. Нужно сделать поддержку инклудов, избавится пока от блока констант, перейдя полностью на имена и убрать лишнее в самом скрипте, оставив лишь самое основное (в смысле мне сейчас нафиг не нужны все 256 интерфейсных понятий и еще кой чего с ними связанное). Кроме того завяжу пока с протоколами, т.к. выяснилось что передавать/принимать все равно нечего…пока.Короче продолжу «вылизывать» архитектуру, а то начал городить монстра с самого начала, потом не разгребу.
21.12.2002 Выкидываем описание констант «const.txt». Убираем программное введение базовых констант и интерфейсных понятий из модуля constant.pas, а также вообще выкидываем парсер файла описания констант.
В основной скрипт добавлен оператор «$include: filename», где filename — имя файла, который необходимо включить в этом месте. Сначала думал несколько ограничить область интерфейсных понятий, устранив различие верхнего и нижнего регистра символов и, возможно, оставив лишь русские буквы, но теперь думаю на данном этапе знание человеческого языка даже не нужно, это лишнее усложнение на этапе отладки. Правда остается открытым вопрос чему же тогда вообще учить эту тварь… 🙂
22.12.2002 Чему учить пока так и не придумал, но в любом случае нужен некий первоначальный набор понятий, который понадобится для любой задачи, например понятие множества. Потестил БД, нашел пару глюков, проверил работу инклудов, сделал выгрузку данных в текстовом а не в бинарном формате.Выгружается все в один файл с расширением .base
При большом количестве элементов базы возникает множество «длинных» связей, что отрицательно влияет на сжимаемость базы а также не дает возможности кластеризации связей, с урезанием разрядности индексов.Короче говоря связанные между собой понятия по возможности должны иметь близкий индекс, тогда можно будет использовать не абсолютные, а относительные индексы, приняв в качестве средней разрядности индекса 16 бит можно было бы вдвое уменьшить затраты памяти а также возможно повысить быстродействие.
Пока выкинул из БД английские символы вообще (вынес их в файл sym_eng.ai) добавил модуль zvuk.ai который представляет собой понятия всех речевых звуков.
12.01.2003 И все — таки до «общения» с системой на человеческом языке очень далеко. Введение в БД звуков и слов ничего не даст без базы понятий, смысла, т.к.сами слова не тождественны понятиям, а по сути лишь являются указателями, ссылками, и модификаторами. Без функционирующей системы понятий не будет и контекста.Может быть стоит пойти по пути создания модульной базы знаний, где каждый юнит/модуль будет содержать связанный по смыслу набор понятий, в нем — же будет указываться его связи с другими модулями, т.е.без которых он не может быть корректно добавлен в систему, т.е. грубо говоря без модуля знания счета и цифр система не сможет подключить модуль знания математики.Меня лишь терзают смутные сомнения…связи между модулями могут быть так многочисленны, что вполне может оказаться невозможным исключение даже одного модуля знаний из общей базы, т.к. на него будут иметься многочисленные ссылки с других модулей, тогда модульное разделение будет носить лишь условный характер, логически разделяя области знания исключительно для удобства программиста.
14.01.2003 Возможно стоит попробовать реализовать модель какой — нибудь игры, например шахмат.Тогда лучше станут видны узкие места системы и недостатки, кроме того при решении подобных задач остается открытой проблема запоминания промежуточных результатов, т.е. придется ли системе использовать внешние по отношению к ней системы хранения временной информации и если нет, то как в терминах системы хранить такую информацию как текущее состояние шахматной доски. И еще я пока плохо представляю как построенная модель может быть использована на практике, т.е. будет ли алгоритм использования данной модели также описан в терминах системы(являться частью общей модели)или реализован как нечто внешнее, не являющееся частью модели.
Шахматы для начала даже сложновато наверное, может крестики — нолики… И вообще следует разработать некоторую теорию построения моделей. В крестиках — ноликах несколько проще, клеток не так уж и много, так что можно каждую описать индивидуально, хотя я думаю не стоит их делить на правые/левые, верхние/нижние, ведь здесь не играет роли какой стороной повернута доска, так что модель должна учитывать возможность разворота доски в процессе игры. Как минимум можно выделить несколько особых клеток — центральная например, остальные делятся на угловые и средние.Но может я опять зашел не с той стороны… самое основное это правила игры, на них и нужно основывать модель, а игровая доска может и изменить размеры…стать 4 * 4 например, или вообще безразмерной. Для модели нужны такие понятия как понятие играющей стороны (противник-1 / противник-2), понятие клетки, пустой / занятой. понятие фигуры игрока, понятие фигур, выстроенных в линию, понятие линии из клеток,
20.02.2003 Поскольку я довольно много размышлял над тем, чтобы научить систему хотя бы зачаткам программирования, то у меня появились некоторые мысли на этот счет. Например то, что не имеет смысла начинать с формализованных конкретизированных понятий в рамках какого либо языка. Начинать нужно с введения самого понятия алгоритма. Как минимум придется ввести что — то вроде понятия «шаг алгоритма», хотя это скорее похоже не на шаг а на точку, в которой находится исполнитель в текущий момент времени. С каждой точкой алгоритма ассоциируется некоторое понятие, которое собственно и являет собой шаг, задавая вектор и конечную точку этого шага. Алгоритм соответственно может состоять из любого количества таких точек, связанных между собой векторами переходов (шагами алгоритма), которые кроме самого вектора содержат еще и некоторое понятие внутреннего содержания шага (условие либо действие). С этим содержимым, которое для краткости и буду называть шагом нужно разобраться более подробно. Мне не очень хочется разбивать это содержимое на две категории — действие и условие, ведь правильной, основной категорией скорее всего является что — то одно, и по моему это как раз условие.
Действие лишь следствие/результат. Алгоритмы должны оперировать понятиями, это по моему очевидно, вот только пока я не вижу ясно — нужно ли представлять понятия в виде переменных для такого алгоритма…
Тогда входные данные можно представить в виде In_1..In_n а выходные Out_1..Out_n, но поскольку система предполагает оперирование понятиями, то на вход будет подаваться понятие in а на выходе будет понятие out. На данный момент в вышеописанном я вижу пока (еще неясно) основу механизма для обработки/переваривания всей информации в БД. Т.е.это позволит ввести что — то типа системы логических заключений, способной к примеру делать такие вещи:
Имеем, например, логическое заключение/правило, способное по входному понятию решить является ли оно последовательностью.
Работает оно примерно так. На вход поступило понятие — аргумент, у него в предках рекурсивно ищется принадлежность к множеству «первый элемент последовательности», если не находится, то понятие не является конечной последовательностью чего — либо, если находится, то ищется принадлежность к последнему элементу последовательности, если находится то понятие является конечной последовательностью чего — либо, либо не является если не находится соответственно. Здесь правда я пока вижу одну серьезную загвоздку… пока не понятно нужно — ли и если нужно то как ограничивать глубину рекурсивного спуска при переборе предков. Наверное сначала необходимо найти ситуацию для которой это необходимо делать, однако в любом случае механизм рекурсивного спуска реализовать придется, с ограничением спуска либо без. Скорее всего ограничение нужно. Вряд ли это ограничение будет носить количественный характер, скорее правильнее ограничить глубину каким либо качественным переходом. Нужно придумать что — то для примера… По поводу применения данного механизма: Вначале я представлял что он будет применен к новосозданным понятиям для создания связей, но возможно удобней будет посредством этого механизма ввести понятие вычисляемых связей, что должно уменьшить общее количество одновременно существующих связей и решить проблему их пересчета при изменении вычисляющей функции.
24.02.2003 Как минимум рекурсивный поиск по связям в глубину реализовать все же придется. Начата процедура FindRec, но еще не дописана.Нужно добавить ограничение глубины и исключить поиск по уже пройденным узлам.Последнее наверное придется реализовать при помощи списка пройденных узлов.
06.03.2003 В основном прогресс остановился на выборе подходящей задачи. Основные критерии:
1 — интересность
2 — небольшое количество понятий
07.03.2003 Выкинул из модуля базы вообще весь лишний текст и все заглушки, оставив только непосредственно работоспособный код.
10.03.2003 Возможно попробую на основе семантических сетей создать некоторую виртуальную файловую систему, которая была бы дополнением к традиционным FAT и NTFS, но была бы более пригодна для поиска и систематизации. Т.е. некоторая надстройка более высокого уровня. На первом этапе формирования такой сети будет конвертация свойств и связей текущей файловой системы. После чего система будет отражать физическую структуру файлов и папок в виде некоторого графа, в узлах которого будут файлы, связанные между собой ассоциативными отношениями. Для практического применения необходимо иметь в системе еще и символьное представление таких понятий как файлы и папки, но пока это я оставлю в покое и ограничусь простым списком символьных ярлыков, каждый из которых будет противопоставлен своему узлу семантического графа. Для этой цели мне даже не придется создавать ничего нового, поскольку уже имеется система «примечаний», прекрасно подходящая на роль системы «ярлыков».
Написана процедура, которая рекурсивно сканирует директории и генерирует скрипт, который потом можно скормить компилятору, наряду с другими скриптами.
Исправлен баг в процедуре GetAss.
Сгенерил скрипт на основе структуры диска D — получилось почти 24000 узлов/понятий. Компилятору уже необходим прогресс-бар 🙂
Прогресс бар не помогает, после обработки 10000 строк процесс компиляции замедляется до скорости 50 строк в секунду. Основные затраты времени должны быть на поиск необходимого идентификатора. Так что придется как-то это ускорять.
Применил технологию хэширования. Ускорение компиляции примерно в 17 раз. Пока хэш вычисляется простым суммированием всех кодов символьной строки. Максимальный размер таблицы 4096 хэш-значений.
Провел тестирование на скорость работы TStringList с большим количеством строк. Рост количества строк слабо влияет на скорость, главное чтобы все в память умещалось 🙂
Один из методов уменьшения объемов — технология виртуальных связей. Т.е. к примеру имеется 50 узлов графа, у которых имеется одно и то же свойство, и если все они имеют общего предка то это свойство может быть присвоено лишь ему, а у всех потомков это свойство будет присутствовать виртуально. Возможно даже будет лучше этот механизм сделать скрытым, чтобы все выглядело так как будто у потомков действительно имеется это свойство. Т.е. новая ассоциация, присвоенное узлу будет распространяться на всех потомках по линиям master/detail в сторону detail. Соответственно все ассоциации группы master или detail должны будут принадлежать к этой группе (входить в это множество).
Неприятная новость: Сохраненный в файл TStringList назад не загружается, чего собственно и следовало ожидать. Для таких целей придется клепать свою процедуру выгрузки/загрузки. Выгружать в текстовой формат по видимому особого смысла нет, кроме случая, когда при выгрузке будет генерируется скрипт.
31.03.2003 Рассуждения на форуме о размерности пространства шахматной доски заставили меня задуматься над этим вопросом. Как определить размерность пространства? Есть ли универсальные критерии? Почему наиболее естественно для нас представлять даже такую ограниченную плоскость как шахматная доска двумя координатами? Ведь здесь можно запросто уложится и в одну, просто пронумеровав клетки. Для упрощения представим что пространство в котором мы существуем дискретно, т.е. грубо говоря мы можем разбить наш мир на клетки, как шахматную доску. Сможем ли мы в этом случае воспользоваться одной координатой вместо трех? Очевидно что нет, ведь пространство бесконечно в любую сторону. Шахматная доска это частный случай, но здесь все точно то же. Представим к примеру что числа у нас могут быть от 0 до 7, т.е. три двоичных разряда. Очевидно что в таком случае потребуется два числа для представления. Если мы возьмем двоичное число разрядностью в 1 бит, то нам потребуется 6 таких чисел. Т.е. получается шести-мерное пространство это максимум. Таким образом мерность пространства напрямую зависит от того чем его измерять и соответственно бесконечное пространство не измерить конечными единицами. Теперь рассмотрим саму единицу измерения… как вы не заметили? ведь это есть ни что иное как пространство! точно такое же, ничем не отличающееся от любых других пространств. К примеру любая числовая переменная представляет собой банальное одномерное пространство, бесконечное в обе стороны. Это может быть и конечным пространством — например переменная длиной N бит. Определяя мерность пространства мы просто сравниваем одни пространства с другими. Удобнее всего оказались бесконечные одномерные пространства, отсюда и определение нашего трехмерного через три одномерных. Это удобство и не более.
Вывод: любое пространство измеряется при помощи другого пространства.
Итого: минимальное одномерное пространство доступное нам — 1 бит, максимальное — целое от нуля до бесконечности (вещественные числа это уже двумерное пространство). Таким образом нетрудно увидеть что вопрос представления пространства шахматной доски — лишь вопрос удобства и количество измерений режет в диапазоне 1..6.
А теперь представьте бесконечную плоскость, разбитую на квадраты. Какова минимальная размерность плоскости? 2? Думаю большинство так и подумало 🙂 Я кстати тоже не далее как полчаса назад… но нет, оказывается и эту плоскость можно представить в виде одномерного бесконечного пространства.
28.04.2003 Ничего интересного идея дискретных пространств не дает: ) А жаль.
Снова переделка главного модуля.Решил внести предельную четкость в термины БД, перестать оперировать невнятными терминами типа «понятие» или «ассоциация». Вместо них вводится более конкретное — узел / точка / Point и связь / Link.Так будет больше ясности и для меня в том числе.
Основная работа переключилась на проект FBD, в который и переехал главный модуль БД.
Из основного модуля убрана процедура Save.
03.05.2003 Низкоуровневый модуль работы с БД — UBD, далее идет модуль первого уровня — UBD1.
В основной модуль наряду с хранением примечаний добавлено хранение имен.
Имена хранятся в одной строке с примечанием, но отделяются от него символом ‘:’
В начале строки идет имя, после ‘:’ идет примечание.По умолчанию присваивается ‘-‘;
Примечанием или именем может быть пустая строка, но они не должны содержать ‘:’
Переписаны процедуры сохранения и загрузки. Выгружается в два текстовых файла FileName.note (имена + примечания), FileName.point (данные о связях)
05.05.2003 Пишется визуальный редактор. Похоже будет удобно иметь не одну глобальную карту на весь граф, а много локальных. Вплоть до отдельной карты на каждое понятие. Карта хранится в PointMap. Строка на узел. Формат строки — номер узла, x, y, width, height — через запятую. Количество описанных узлов в строке соответствует количеству узлов в локальной карте для заданного узла.
06.05.2003 Сделал загрузку данных из файла. Вынес визуальную работу в модуль PointForm, в перспективе можно будет открывать несколько форм для различных операций.
08.05.2003 Работа над редактором.
09.05.2003 Работа над редактором.
Средства редактирования стараюсь максимально визуализировать. Создана панель работы со связями узлов, добавлен чекбокс автореверса связей (почти все связи будут двунаправленные, при включенном автореверсе будет подбираться реверсивный тип связи, скорей всего для этого будет использован тип связи ToInverse).
12.05.2003 Устранен страшный глюк в загрузке данных из файла.
Начал сооружать пробную модель файловой системы.
21.05.2003 Работу с файловой системой надо делать немного не так как я себе это представлял. Лучше всего абстрагироваться от всех мелочей а также уйти от способа указания файла по его пути. Для этого будет предусмотрен спец.модуль.Который будет искать файл по его ID и наоборот.А также следить за обновлением, перемещением, переименованием либо удалением файлов.
Будет создан модуль Files. Пока для идентификации файла я скорей всего ограничусь его путем, именем и размером.Потом возможно добавится еще и контрольная сумма.
08.06.2003 Создание нового «компилятора»(unit Compiler)
формат строки — разделитель подстрок ‘:’
include: FileName — включить файл
p: PointName: PointNote — новый поинт
l: PointFrom: PointTo: LinkType[:InverseLinkType] — создание связи
в модуль bd добавлена процедура clear
22.06.2003 Возникла надобность в некоторых функциях, работающих с множествами узлов. Эти множества должны передаваться в качестве параметров и результатов.Основных вариантов два — поступить стандартным методом (передавать массивы), или средствами БД организовывать множества и передавать только идентификатор. Второе однозначно тормознее, но потенциально интересный вариант, например становится возможной передача иерархически организованных данных.Попытаюсь пока остановиться на этом варианте, мне он кажется несколько гибче.Все процедуры буду запихивать в unit ProcDM.
23.06.2003 Попытка создания некоторого интерпретатора, который будет последовательно выполнять команды, пользуясь стеком для передачи параметров.
Нужен компонент для построения таблиц. В качестве исходных данных передается Point на таблицу, который детейлами содержит строки, а строки в свою очередь детейлами содержат столбцы.(таблица = иерархический список второго уровня)
24.06.2003 Грабли оказались там где я их не ожидал.Короче говоря любая ассоциация класса master или detail должна напрямую быть детейлом соответствующего множества. Иначе я не могу определить ее принадлежность. Или даже может нужно сделать еще более тупо — ассоциации master и detail не могут иметь потомков.
30.06.2003 В качестве параметров процедуре построения таблицы должна также передаваться ссылка на метаданные. В данном случае метаданные будут иметь вид:
p: CDDisk: множество дисков
l: MyCD: CDDisk: detail: master
p: CDName: наименование CD
l: CDDisk: CDName: detail: master
p: CDComment: коментарий к CD
l: CDDisk: CDComment: detail: master
p: CDNumber: номер CD
l: CDDisk: CDNumber: detail: master
Где:
CDDisk — множество строковых элементов таблицы
CDName, CDComment, CDNumber — элементы строки таблицы
Отображение таблицы вроде заработало, но мне не нравится довольно громоздкая запись процедуры проекции данных в таблицу.
16.07.2003 При помощи построения вспомогательных таблиц решена проблема определения принадлежности поинта к master или detail
Proc.CreateMasterList — строит вспомогательную таблицу,
функции:
function IsMasterLink(Point: integer): boolean;
function IsDetailLink(Point: integer): boolean; — поверяет принадлежность.
18.07.2003 Метод интерпретации:
Если Point является детейлом от ExecutionPoints происходит исполнение, иначе Point кладется на стек.
Пример:
StartPoint ForAllLinks detail ifEqual
^стартовая точка
^разделение потоков по количеству связей
Запись представляет собой цепочку указателей, где каждое звено ссылается на следующее, а тип ссылки указывает на действие(является потомком от ExecutionPoints), либо на параметр (является потомком от ToStack). При анализе очередной позиции вначале выполняется обработка ToStack связей, а потом всех ExecutionPoints. Порядок перебора связей внутри этих двух групп ничем не определяется.
форма записи:
:ProcPoint n1 n2: Test000Point n3 n4 end
Токен, предваренный двоеточием, представляет собой имя узла, может встречаться в любом месте для именования узлов и возможности ссылаться на них.
19.07.2003 unit itpDM содержит класс Titp, являющийся интерпретатором и имеющий точку входа Titp.Run(StartPoint: integer)
Все ExecutionPoints делятся на:
— базовые(встроенные)процедуры.
— готовые процедуры.
— методы ветвления хода выполнения.
Модуль исполнения реализован так что последовательно будут пройдены все точки графа.
24.07.2003 Основной цикл модуля исполнения написан. Сегодня хотел начать с основ — реализовать процедуры, но как оказалось при текущем методе реализации отпадает необходимость доработки основного цикла, что безусловно является хорошим знаком.
27.07.2003 Подход когда указатели явно задаются в теле процедуры не годится, т.к. от этого теряется реентерабельность кода. Такое годится разве что для констант.
01.09.2003 Пока стек данных.
03.09.2003 Идея полного исключения циклов и переборных алгоритмов из интерпретируемого кода. «Много-тредовость» — интерпретатор для каждой обнаруженной связи запускает новый процесс, передавая в качестве параметра свое полное состояние, который гаснет после обработки связи. Таким образом решается задача «авто-расщепления» основного процесса на множество параллельных, а также задача авто-завершения. Еще есть вариант что при обработке данных в случае если процедура требует входным параметром одну связь, а их более одной — тоже расщеплять процесс, передавая каждому экземпляру свою порцию данных.
05.09.2003 Процессы должны стартоваться событиями, а параметром будет Sender.
20.09.2003 Много-корневые деревья.
Основным видом отношений между узлами являются master-detail отношения. Так как эти отношения всегда существуют в паре, то между собой их должен объединять третий (обобщающий узел), детейлами которого они должны являться. Так как эти отношения сами являются узлами, то называть их буду master-point и detail-point, а обобщающий узел md-point.
Создание интерфейса к многокорневым деревьям. Для визуального построения такого дерева необходимо указать md-point.
Необходимы операции над множествами.
— пересечение, вычитание, суммирование.
добавлена процедура удаления связи
procedure TBD.DelLink(Point, LinkNum: integer);
21.09.2003 Процедура удаления узла и всех ссылок на него (не находит и не удаляет ссылки типа LinkType)
procedure TBD.DelPoint(Point: integer);
это нужно для tmp-узлов (промежуточных расчетов)
procedure TProc.CreateLinkMD(MPoint, DPoint: integer);
05.10.2003 Начинаем по новой 😉 (Многокорневые деревья)
— Деревом считается набор точек, соединенных между собой отношениями
master,detail и имеющие одну корневую точку, для обозначения которой
в этом тексте будет использоваться «LRoot»(LockalRoot).
— Каждое дерево для обозначения внутренней иерархии использует свой набор связей.
Эти два вида связей указываются из точки LRoot при помощи указателей
LMaster и LDetail (Обратные связи соответственно LMaster_, LDetail_)
Для обозначения этих двух видов связей в тексте буду использовать обозначения
LRoot_d и LRoot_m. LRoot_d соответственно должен быть детейлом от detail а LRoot_m детейлом от master.
— Точка может быть одновременно вершиной только одного дерева.
Создано графическое отображение дерева.
08.10.2003 Попытка реализовать механизм перехода между деревьями. Чтобы составить список всех деревьев в которые входит Point перебираем все связи. Если найдена связь LMaster то это говорит о том что этот узел является корнем дерева, а значит заносим его в список.
05.11.2003 В первую очередь необходимо уделить внимание методике извлечения таблиц из БД.
06.11.2003 Реализовано нечто вроде стекового буфера обмена (M+) для запоминания текущего Point.
Реализовано добавление вершины из буфера обмена.
+ Процедура конвертации выбранной точки в вершину дерева.
Мелкое причесывание кода.
Добавление мелких, но часто юзаемых и повышающих наглядность кода процедур поиска линков
function FindLinkType(Point, LType: integer): integer;
function FindLinkTo(Point, LTo: integer): integer;
function FindLinkTT(Point, LTo, LType: integer): integer;
Выделение в модуле ProcDM Процедур поддержки технологии «мульти-деревьев»
procedure PrepareConstants;
procedure ConvertPointToLRoot(P: integer);
procedure DelPointFromTree(Point, Tree: integer);
procedure FindTreeMD(RootPoint: integer; var RootM, RootD: integer);
09.11.2003 Построение таблиц.
Таблица задается одной вершиной — будем называть ее корнем таблицы (Table). Дерево Table содержит вершины, являющиеся измерениями таблицы. Для одномерной таблицы (списка) дерево Table будет содержать всего одну вершину, для двумерной — две и т.д. При этом где у двумерной таблицы вертикальное измерение а где горизонтальное в принципе не важно. Каждое дерево измерения содержит вершины, являющиеся строками (столбцами) таблицы, ну а каждая строка содержит соответственно набор вершин, являющихся значениями ячеек таблицы. При построении таблицы последовательно перебираются строки и столбцы, и при нахождении пересечения множеств точка пересечения считается значением ячейки.
14.11.2003 Для извлечения таблиц нужен алгоритм поиска пересечения деревьев.
Поиск пересечения двух деревьев:
function TProc.CrossTree(Tree1, Tree2: integer): integer;
Для удобной работы с деревьями создан класс TTree
Свойство Root указывает на корень дерева. Выставляется вручную.
Count — количество узлов в дереве (включая корневой)
M,D — типы связей для данного дерева (to_master,to_detail)
При указании корневого узла (Root) сразу же формируется список узлов дерева, к любой точке которого можно обращаться примерно так: Tree[N]
Написана тестовая процедура построения таблицы в виде HTML.
Пока не понятно как организовывать последовательности. Логично было бы сделать их в виде дерева — следующий элемент является веткой предыдущего, но пока непонятно, будет ли это удобно, особенно для больших последовательностей
15.11.2003 Последовательности можно реализовать в виде отдельного элемента, такого как дерево. Но любое дерево, как и последовательность это в конечном итоге множество. Значит последовательность можно представить в виде дерева, в котором узлы кроме отношений мастер-детейл связаны еще и отношением next-prev. С корневого элемента будет идти указатель first и last (обратно соответственно first_,last_). В простейшем случае дерево будет одноуровневым, и все элементы будут связаны в единственную цепочку, но непонятен пока вопрос может ли узел ссылаться на несколько next или prev узлов, и нужно ли это.
Пока склоняюсь к варианту «одно дерево — одна последовательность».
16.11.2003 Если объекту TTree в качестве корневой указывается точка, которая на самом деле не является корневой вершиной дерева то Count=0. Доработка редактора (разные мелкие фичи типа горячих клавиш и удобства навигации)
17.11.2003 Для простоты и наглядности неплохо бы создать объект TPoint.
В навигаторе сделать кнопку «назад»
Добавить лог, который можно было бы использовать для отката назад.
Кажется нет надобности давать вспомогательным узлам (невидимым для пользователя) имена типа 354_m, это только лишний расход памяти…
По клавише F7 в корень ветки добавляется новое значение и сразу осуществляется переход в режим редактирования.