В этом примере, как мы уже обсуждали, ровно одно событие (и оно, на самом деле, просто триггер, в реальности мы анализируем набор данных, начинающийся с карты, с которой сходил противник).
Так и есть одно событие, остальные уже стали состояниями. Правильно ли я понимаю, что переименование события в условие (так сказать, элементатное, неделимое условие) решит проблему? Ну а ситуация стало быть это сложное (составное) условие.
А почему обязательно на этом подходе? Чем этот подход лучше любого другого?
Он похож на подход, которым человек объясняет правила (чего либо) другому человеу. Я приводил пример с объяснением хода в карточной игре. Вот в этом причина. Программирование по фотографии посредством процесса коммуникации. Этот подход по моему скромному мнению как раз то, что нужно.
И никакого «значение переменно изменится на другое» у вас тоже не будет — вы просто выбросите все дерево целиком
Как раз этого не планировал. Раз уж переменные глобальные (по крайней мере пока), будем посторно их использовать. А это значит, что в переменной до слова «мама» было значение из предыдущего предложения. И после его обработки это уже неинтересный мусор
Вот не надо за меня додумывать мои ответы. Если нам нужна система со внешним обучением, то совершенно не обязательно, что ее обучает программист. И да, ему надо дать инструмент для этого обучения… вот только вы определитесь, вы хотите разработать такой инструмент, или парадигму программирования?
Инструмент. Но на этом подходе. Описал его, чтобы потом иметь возможность ссылаться. Да и сам тогда понимаешь лучше.
но вот называть каждое условие событием — строго ошибочно.
Ну это игра терминов. Собствено, почему изначально назвалось событием, потому что переменная означающая актора изменилась со значения Х на значение «мама». Произошло событие. Это потом стало ясно, что оно имеет свойства и состояния, потому что оно не перестанет быть активным, пока значение переменной не измениться на другое. А ситуация это уже больше похоже на условие, когда одновременно имеют значение несколько событий.
Да нет никакого «грузим проводки», откуда вы его берете?
Оттуда что разрабатывал и внедрял банковское ПО.
Вот у вас игрушечная платежная система в интернетике. В один и тот же момент (а) пользователь решил перевести деньги на другой счет (б) активировалась запланированная операция и (ц) пришло списание из интернет-магазина.
Ну а как такие конфликты решаются обычно. При помощи Logical unit of work, или по нашему ранзакциями. Какой платеж первым заблокировал данные, тот и обрабатывается. Остальные лочатся и ждут завершения транзакции. Эти механизмы можно надеть на любую парадигму. Не стоит на них сосредотачиваться.
Экземпляры обработчиков-то ладно, а что вы с данными будете делать
Ничего не буду делать. В каждом отдельном потоке: ждем, пока остатки на счетах отпустят другие потоки, лочим их, меняем остатки обоих счетов, отпускаем для других потоков.
Это не имеет отношения к парсингу текста. Вы постоянно перепрыгиваете из задачи в задачу.
Имеет, никто никуда не прыгает. Непосредственно разбор предложения и построение синтаксического дерева это только полдела. Если база знаний содержит даты рождений и может ответить на вопрос «Когда родлися Х?» то не факт, что имея данные об объемах двигателей она сможет ответить на вопрос «Объем двигателя модели Х больше объема двигателя модели Y?» Этот вопрос сравнительного характера, он более сложный, система должна его распознать. Кто будет добавлять возможность отвечать на новые типы вопоросов? Вы ответите — программист, и будете правы. А я отвечу — обычный человек будет это делать, не программист, он даже в код смотреть не будет. И я тоже буду прав. Только этому человеку соответствующий инструмент нужно дать.
есть тысяча и один подход,
Ок, этот будет тысяча вторым. Я же не говорю, что на нем свет клином сошелся.
Продолжаю не понимать, откуда у вас там события.
На любые входные данные можно наложить события. А для вычленения определенной совокупности входных данных (конкретный набор слов) эти события можно сложить в ситуацию и и работать как с целым.
Пример:
Допустим имеем на входе простое предложение из подлежащего (актор) сказуемого (действие) и дополнения (актант): «Мама мыла раму.» Мы можем навесить на слово «мама» событие, которое будет выстреливать каждый раз когда на входе актором будет слово «мама». На слово мыть мы тоже навешиваем событие, как и событие на слово «рама» в качестве актанта. Объединяем все ри события в ситуацию. Не смотря на то, что поотдельности эти 3 события будут активироваться на совершенно разные предложения, вместе, т.е. ситуация их объединившая, активируется только для одного конкретного случая, а именно входного предложения «мама мыла раму». И только для этого предложения сработает обработчик этой ситуации.
Да, разве не возможна псевдопараллельность в одном потоке, когда изменениями состояний эмулируется одновременное выполнение нескольких циклов?
Например, есть n обработчиков ситуации «баланс счета выше 100». Как обеспечить консистентность их работы?
Не понимаю я этого. N перегруженных обработчиков? Но такого ничего не будет. А если в рантайме, то в единицу времени одни обработчик для текущего обрабатываемого счета. Мы же проводки все равно поодиночке грузим, хоть сервис, хоть что. А если нужно параллельно, то запускаем отдельный процесс и грузим отдельно, экземпляры обработчиков там свои будут.
(Замечу, что даже в вашем предполагаемом применении без параллелизма не обойтись)
Пока обходился. Для каждого нового запроса создаю новый поток со своим экземпляром интерпретатора.
Эта задача вообще не требует «событий» и «ситуаций», она фиксирована и не меняется во времени.
Это процесс обучения, добавление нового поведения, корректировка уже заложенного поведения.
Вот сечас более точно сформулировался ответ на ваш вопрос. Этот подход может пригодиться в машинном обучении с учителем (а возможно и без). Когда доступ к коду не обязателен, или отсутствует.
Вы не поняли мой вопрос. Я спрашиваю, какие задачи будет решать эта система — проще говоря, зачем она нужна?
Информационно-поисковая система позволяющая точно описывать то, что требуется найти. Не коммерция, чисто исследовательская работа.
Позвольте и мне задать ворос. Отчего такой интерес? Вы же никаких преимуществ для себя не отметили.
Если обработчики выполняются последовательно, то не важно, из каких потоков.
В одном потоке точно будут выполняться только последовательно, но для разных пока не регламентировано.
Что вы понимаете под лингвистическим процессором? Разбор фразы?
Да, разбор вопроса и поиск ответа.
Описать ситуацию на естественном языке — это одно дело. А среагировать на нее — это другое дело.
Инструкции будут на том же языке. Это как раз второй подход, про который я говорил. Т.е. один язык для обмена информацией и для ее обработки. Эта тема заслуживает отдельной статьи. Подход тоже спорный и также не всем будет понятен.
Предположим, ситуация описана (не важно, естественным языком, или DSL). Какую функцию будет выполнять сама система, которая эти ситуации обрабатывает и реагирует на них?
Обработчик будет содержать инструкции на том же языке, которые будут надиктовываться системе через тот же интерфейс, что и запросы к базе данных.
Вы представляете себе алгоритмическую сложность решения такой задачи? По идее, конечно, это обычная топологическая сортировка с выявлением колец, но мне почему-то кажется, что наличие условий либо сделает этот граф гигантским (а там все-таки NC2), либо переведет в другой класс.
Потому тогда вначале и написал, что работоспособность такого подхода еще предстоит доказать.
Во-первых, «блокировки на переменные» вам не нужны: если вы сказали, что у вас обработчики выполняются только последовательно, у вас никогда не будет одновременного обращения.
Теоретически, могут быть обращения из других потоков, между вызовами обработчиков в текущем потоке. Но это потом, не заморачиваюсь я сейчас темой параллелизма.
Кстати, а для каких задач оправдан ваш подход, по-вашему?
Не хотелось бы чтобы ответ получился вырванным из контекста. Я хочу проверить это на базе знаний со встроенным языком. Т.е. когда запрос к базе знаний создается на естественном языке и база знаний отвечает. Так вот лингвистический процессор возможно сможет работать на таком подходе. Тогда в него можно будет добавлять новые возможности (разбор более сложных форм вопросов) без непосредственного вмешательства в код. Можно будет на естественном языке описывать ситуацию и как нужно действовать, когда она наступит.
С первого вопроса начиналась наша дисуссия. Планирую определять порядок выполнения приоритетами. В момент начальной загрузки каждого обработчика в нем проверяются зависимости и выставляется приоритет. Это пока первый приоритет.
По второму вопросу не ясно, блокировки на переменные может какие-то.
Какой-то подход может что-то позволять, а что-то нет. Я только думаю над теорией. Только практика покажет, придется проблему решать, или лучше игнорировать. Сейчас это больше похоже не на игнорирование, а на неполное видение полной картины.
Предполагается что перед выключением двигателя робот переключил трансмиссию в паркинг и колеса блокированы. Ну можно еще показания спидометра анализировать.
Вот, прекрасно, откуда вы ее возьмете?
Да хоть аппаратным прерыванием. Это не важно.
В чем выгода?
Тут ее либо сразу видишь, либо нет.
Ну и самое главное. Пока вы работаете с состояниями — вы вынуждены разделять состояния между обработчиками. Как вы будете разрешать возникающие коллизии?
Ну и да, то, что вы описываете — это полностью последовательная система, со всеми описанными недостатками.
Вы цепляетесь к деталям. Си тоже последовательный, а параллельность работы потоков контроллируется объектами ядра (семаформаи, мьютексами). Проблема параллельности СУБД решается транзакциями. Это все наживные детали.
Что такое «встретилась преграда»? Событие? Состояние?
Давайте рассмотрим ситуацию, более подробно. Имеет ли смысл машине задействовать тормоз, если двигатель выключен, но перед ней появился пешеход? Нет.
Имеет ли смысл машине задействовать тормоз, если двигатель включен, но коробка в режиме нейтрали или паркинга, хотя опять же перед ней появился пешеход? Нет. Значит ситуация, при которой нужно останавливается актуальна только тогда, когда двигатель работает, и передача включена. Стало быть у нас есть переменная на Вкл./Выкл двигателя и переменная на номер текущей передачи, ну и конечно переменная отражающая наличие препятствия на дороге. У нас есть 3 события на каждую их переменных. Первое событие на то что двигатель включен, второе, на то что включена соответствуяющая передача. И последнее событие на наличие помехи спереди. На основе 3х событий создаем ситуацию.
Теперь. Робот включает двигатель, срабатывает первое событие. Оно превращается в состояние. Т.е. это флажок и он будет взведен, пока робот не выключит двигатель. После включения двигателся робот включает первую передачу и начинает движение. Срабатывает второе событие и переводится в режим состояния. Но ситуация вызваться не может, т.к. остается неактивированным последнее событие. Имеем 2 активированных события и одно неактивное. Если сейчас выключить двигатель, то деактивируется первое событие, а для того, чтобы сработала ситуация и выполнился ее обработчик должны быть одновременно активными все события, привязанные к ситуации.
Очевидность тут субъективное понятие. Довольно тяжело было переходить на ООП после процедурного в конце 90х. Теперь же тяжело дается понимание функциональщины. Вроде и понятно, но мозг уже привык к ООП.
Нет, он как раз очень хорошо подметил. На переменные навешиваются события (состояния), которые группируются в ситуации. Одно событие может быть привязано к разным ситуациям.
Это надстройка над событийно-ориентированным программированием.
Отличается наличием диспетчера, который мониторит состяние и запускает «ситуации», если «условия» сработали.
Позволяет упростить программирования за счет абстрагирования от разделяемого состояния. «Ситуации» и «условия» как раз его и абстрагируют
Для встроенных систем такой подход не самое лучшее решение из-за быстродействия. Возможно сигналы от датчика будет обрабатывать промежуточный микроконтроллер, который уже будет подавать сигнал «наверх». В таком случае машина будет продолжать движение, пока не встретилась преграда, срабатывает ситуация и машина либо пытается объехать препятствие, либо остановиться.
Параллельно две ситуации «сумма на счету превысила сто рублей» возникнуть не могут. Мы загружаем проводки из файла последовательно, запись за записью. Для каждой строки в процессе ее обработки может взвестись флажок и включиться соответствующий обработчик.
по фотографиипосредством процесса коммуникации. Этот подход по моему скромному мнению как раз то, что нужно.Как раз этого не планировал. Раз уж переменные глобальные (по крайней мере пока), будем посторно их использовать. А это значит, что в переменной до слова «мама» было значение из предыдущего предложения. И после его обработки это уже неинтересный мусор
Ну это игра терминов. Собствено, почему изначально назвалось событием, потому что переменная означающая актора изменилась со значения Х на значение «мама». Произошло событие. Это потом стало ясно, что оно имеет свойства и состояния, потому что оно не перестанет быть активным, пока значение переменной не измениться на другое. А ситуация это уже больше похоже на условие, когда одновременно имеют значение несколько событий.
Ну а как такие конфликты решаются обычно. При помощи Logical unit of work, или по нашему ранзакциями. Какой платеж первым заблокировал данные, тот и обрабатывается. Остальные лочатся и ждут завершения транзакции. Эти механизмы можно надеть на любую парадигму. Не стоит на них сосредотачиваться.
Ничего не буду делать. В каждом отдельном потоке: ждем, пока остатки на счетах отпустят другие потоки, лочим их, меняем остатки обоих счетов, отпускаем для других потоков.
Имеет, никто никуда не прыгает. Непосредственно разбор предложения и построение синтаксического дерева это только полдела. Если база знаний содержит даты рождений и может ответить на вопрос «Когда родлися Х?» то не факт, что имея данные об объемах двигателей она сможет ответить на вопрос «Объем двигателя модели Х больше объема двигателя модели Y?» Этот вопрос сравнительного характера, он более сложный, система должна его распознать. Кто будет добавлять возможность отвечать на новые типы вопоросов? Вы ответите — программист, и будете правы. А я отвечу — обычный человек будет это делать, не программист, он даже в код смотреть не будет. И я тоже буду прав. Только этому человеку соответствующий инструмент нужно дать.
Ок, этот будет тысяча вторым. Я же не говорю, что на нем свет клином сошелся.
На любые входные данные можно наложить события. А для вычленения определенной совокупности входных данных (конкретный набор слов) эти события можно сложить в ситуацию и и работать как с целым.
Пример:
Допустим имеем на входе простое предложение из подлежащего (актор) сказуемого (действие) и дополнения (актант): «Мама мыла раму.» Мы можем навесить на слово «мама» событие, которое будет выстреливать каждый раз когда на входе актором будет слово «мама». На слово мыть мы тоже навешиваем событие, как и событие на слово «рама» в качестве актанта. Объединяем все ри события в ситуацию. Не смотря на то, что поотдельности эти 3 события будут активироваться на совершенно разные предложения, вместе, т.е. ситуация их объединившая, активируется только для одного конкретного случая, а именно входного предложения «мама мыла раму». И только для этого предложения сработает обработчик этой ситуации.
Не понимаю я этого. N перегруженных обработчиков? Но такого ничего не будет. А если в рантайме, то в единицу времени одни обработчик для текущего обрабатываемого счета. Мы же проводки все равно поодиночке грузим, хоть сервис, хоть что. А если нужно параллельно, то запускаем отдельный процесс и грузим отдельно, экземпляры обработчиков там свои будут.
Пока обходился. Для каждого нового запроса создаю новый поток со своим экземпляром интерпретатора.
Это процесс обучения, добавление нового поведения, корректировка уже заложенного поведения.
Вот сечас более точно сформулировался ответ на ваш вопрос. Этот подход может пригодиться в машинном обучении с учителем (а возможно и без). Когда доступ к коду не обязателен, или отсутствует.
Информационно-поисковая система позволяющая точно описывать то, что требуется найти. Не коммерция, чисто исследовательская работа.
Позвольте и мне задать ворос. Отчего такой интерес? Вы же никаких преимуществ для себя не отметили.
Да, разбор вопроса и поиск ответа.
Инструкции будут на том же языке. Это как раз второй подход, про который я говорил. Т.е. один язык для обмена информацией и для ее обработки. Эта тема заслуживает отдельной статьи. Подход тоже спорный и также не всем будет понятен.
Обработчик будет содержать инструкции на том же языке, которые будут надиктовываться системе через тот же интерфейс, что и запросы к базе данных.
Теоретически, могут быть обращения из других потоков, между вызовами обработчиков в текущем потоке. Но это потом, не заморачиваюсь я сейчас темой параллелизма.
Не хотелось бы чтобы ответ получился вырванным из контекста. Я хочу проверить это на базе знаний со встроенным языком. Т.е. когда запрос к базе знаний создается на естественном языке и база знаний отвечает. Так вот лингвистический процессор возможно сможет работать на таком подходе. Тогда в него можно будет добавлять новые возможности (разбор более сложных форм вопросов) без непосредственного вмешательства в код. Можно будет на естественном языке описывать ситуацию и как нужно действовать, когда она наступит.
По второму вопросу не ясно, блокировки на переменные может какие-то.
Вроде бы всегда отвечаю на конкретное сообщение, но хабр иногда перепривязывает не туда. Не знаю что это
А, только последовательно. Они могут друг от друга зависеть.
Да хоть аппаратным прерыванием. Это не важно.
Тут ее либо сразу видишь, либо нет.
Тут не уловил, какие коллизии?
Давайте рассмотрим ситуацию, более подробно. Имеет ли смысл машине задействовать тормоз, если двигатель выключен, но перед ней появился пешеход? Нет.
Имеет ли смысл машине задействовать тормоз, если двигатель включен, но коробка в режиме нейтрали или паркинга, хотя опять же перед ней появился пешеход? Нет. Значит ситуация, при которой нужно останавливается актуальна только тогда, когда двигатель работает, и передача включена. Стало быть у нас есть переменная на Вкл./Выкл двигателя и переменная на номер текущей передачи, ну и конечно переменная отражающая наличие препятствия на дороге. У нас есть 3 события на каждую их переменных. Первое событие на то что двигатель включен, второе, на то что включена соответствуяющая передача. И последнее событие на наличие помехи спереди. На основе 3х событий создаем ситуацию.
Теперь. Робот включает двигатель, срабатывает первое событие. Оно превращается в состояние. Т.е. это флажок и он будет взведен, пока робот не выключит двигатель. После включения двигателся робот включает первую передачу и начинает движение. Срабатывает второе событие и переводится в режим состояния. Но ситуация вызваться не может, т.к. остается неактивированным последнее событие. Имеем 2 активированных события и одно неактивное. Если сейчас выключить двигатель, то деактивируется первое событие, а для того, чтобы сработала ситуация и выполнился ее обработчик должны быть одновременно активными все события, привязанные к ситуации.
Параллельно две ситуации «сумма на счету превысила сто рублей» возникнуть не могут. Мы загружаем проводки из файла последовательно, запись за записью. Для каждой строки в процессе ее обработки может взвестись флажок и включиться соответствующий обработчик.