Здравствуйте, Pzz, Вы писали:
Pzz>Ты суть-то опиши. В чем кайф от этой машины? А то твои математические определения скучно читать, пока не поймешь, зачем?
Он уже описывал примерно 10 лет назад, но был высмеян за использование уникальной авторской терминологии.
Сейчас сделал второй подход, но кроме другой терминологии отличий не вижу.
В двух словах, в чём ключевое отличие его "уникального способа" от классического.
Программа, по-сути, строится и видоизменяется "на лету".
На каждом шаге может сработать паттерн "стратегия" и прочие родственные, типа "фабрика" и т.д., которые, в свою очередь, могут изменить структуру программы.
Подобные трюки я иногда применяю для ускорения "горячих" мест, например, по неким развесистым условиям программа пробегается лишь однажды, строя на лету через (в идеале даже не ООП-стратегии, а просто указатели на ф-ии), в общем через какой-либо из механизмов косвенности/виртуализации на лету стрится требуемая "прямая" логика, которая будет работать в цикле до некоторых пор уже без повторных проверок условий. При смене внешних условий может сработать обработчик соответствующего события и перестроить программу.
Т.е., условно нелинейная логика каждый раз строит условно линейную программу (потому что "исполнитель" тупой-линейный).
Два этих действа в предлагаемой парадигме равноправны, потому что "нелинейная" программа строится и исполняется так же, это я просто пытаюсь отделить мух от котлет на живых примерах, с целью разгрести всю эту забористую кашу.
Автор захотел выделить подобный подход нон-стоп "реконфигурирования" в чистом виде, но запутался в ролях и придумываниях терминологии.
(язык программирования и прочий инструментарий тут нужны для большей выразительности описания происходящего, ИМХО, и ни для чего более)
Изначально у элементов этой техники никаких ролей нет (т.е. даже просто пытаться придумывать роли сущностей в отрыве от конкретных задач было ошибкой), а есть просто трюк косвенности (в общем случае — ассоциативной памяти) и перебор получаемых на модели ассоциативной памяти бесконечной комбинаторики эффектов.
Разумеется, это несколько отличается от привычного, "более линейного" программирования, что автору показалось, что он изобрёл новую парадигму.
Не изобрел.
Ассоциативный доступ к данным и подпрограммам — ключевые низкоуровневые технологии современного ПО.
В ООП это виртуальные ф-ии, инкапсулированные в объекты данные, в ФП это абстрактная сигнатура ф-ии, которая также может захватывать в лямбду данные и т.д. до бесконечности, вплоть до банальных адресов обработчиков пронумерованных прерываний в таблице их в программе на асме или си.
Отличие его подхода от классического в том, что подобное "конфигурирование" программы в классике происходит редко (часто вовсе однократно при запуске), вместо чего автор предлагает эксплуатировать подход бесконечного реконфигурирования программы в качестве ключевого этапа работы программы, а не вспомогательного, как оно чаще есть сейчас.
Здравствуйте, Холодный, Вы писали:
Х>Работа предложенной машины можно представить алгоритмом только по выполнению какой-то ветки где порядок определен последовательностью подписок событий оказавшимися истинными по факту выполнения.
Собятия/подписка и т.д. — это уже более высокоуровневые сущности архитектурного плана, не обязательно было называть их именно так, ведь раздача ролей в некотором роде сужает область оперирования.
В основе лежит тот или иной метод абстракции подпрограмм+данных, плюс доступ к этим абстракциям через какой-нибудь способ ассоциации (в ООП через адрес объекта, в ФП через пару — {указатель_на_функцию, указатель_на_захваченные_данные}.
Здравствуйте, Nuzhny, Вы писали:
N>Ты говорил: Х>>Я предлагаю общее решение для широкого класса задач, а не эксклюзивные процессоры N>И это подтверждает, что решение для широкого класса задач, во-первых, теоретически, а во-вторых, уже и практически.
+100500
10 лет назад, когда он впервые распинался об этом же, мы тоже так и не увидели примеров решений популярных программистских задач с использованием этой парадигмы, с обязательным сравнительным анализом.
Для этого необходимо было бы придумать соотв. язык программирования или библиотечную реализацию к имеющемуся, решить на этом языке сотни программистских задач от низкого до высокго уровней, сделать комплексные замеры — производительность, уровни сцепки-связанности архитектурных вещей и даже оценки пресловутого "синтаксического оверхеда".
Но ничего так и не было. Зеро.
Отношение к автору посему случилось понятно какое.
Х>Машина Кузьмина. (Управляемая недетерминированная машина Тьюринга.)
Сначала прочитай книжку Прикладные нечеткие системы
Там японцы еще в конце 1989 года описали конструкцию нечеткого компьютера
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Подучиться бы тебе надо... Х>Текст прочитал?
И еще раз тебе советую: прочитай книжку Прикладные нечеткие системы японских авторов...
нечеткие, а не нечетные...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>И еще раз тебе советую: прочитай книжку Прикладные нечеткие системы японских авторов... LVV>нечеткие, а не нечетные...
Странный ты парень. Ты что считаешь что я гуглом не умею пользоваться? Тем более, ты и ссылку дал. Конечно, посмотрел сразу. Я ж ответил что тема не о том. Я на буквы и внимания не обратил. А вот ты таки не въехал.
Чисто для затравки. Тьюринг своей машиной хотел формализовать алгоритмы, а формализовал нечто большее. https://ru.wikipedia.org/wiki/Алгоритм
Моя машина формализует А-ритмы. Фишка в том, что в общем случае, порядок не гарантирован. И работает на многопроцессорных машинах с несколькими шинами доступа. Для автоматики ИИ это, самое то.
LVV>>И еще раз тебе советую: прочитай книжку Прикладные нечеткие системы японских авторов... LVV>>нечеткие, а не нечетные... Х> Странный ты парень. Ты что считаешь что я гуглом не умею пользоваться? Тем более, ты и ссылку дал. Конечно, посмотрел сразу. Я ж ответил что тема не о том. Я на буквы и внимания не обратил. А вот ты таки не въехал.
Если что, то
а) я ИИ преподавал в 90-хи в начале 2000-х...
б) японцы занимались разработкой архитектур ЭВМ для ИИ с 1981 года 10 лет. И в результате получили нечеткие системы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>б) японцы занимались разработкой архитектур ЭВМ для ИИ с 1981 года 10 лет. И в результате получили нечеткие системы.
Я в курсе. Они тогда разрабатывали новую архитектуру "Управляемую потоком данных" Кстати, очень похоже на то, что я сделал.
