Может, тебе непонятно и ты потому поставил мне минус? Извини, что на ты, но попробую пояснить. Если поймешь, конечно.
Все просто. Очень просто. Все, что работает на современных процессорах "было, есть, и всегда будет алгоритмами". Согласен? И нет такого алгоритма, который бы нельзя было описать/реализовать машиной Тьюринга. Согласен? Следовательно, всегда можно найти машину Тьюринга, которая опишет алгоритм ответа любого известным тебе ИИ. Есть возражения?
Если есть, то - поздравляю! - ты наконец-то опроверг самого Тьюринга. А если еще предъявишь свои аргументы и доказательства, то этот день будет записан в скрижали теории алгоритмов и программирования. И тогда я к тебе буду обращаться только на Вы.
К счастью я немного понимаю, как работает динамик :). С пионерского возраста. Кажется этому учат даже в школе (но я разобрался самостоятельно). Вот если бы динамик вдруг сам запел, то я бы с Вами согласился.
А вот ИИ может. Нужно только определить ему цель. Ну типа: спой под Высоцкого на тему полета нашего недавнего (крайнего) полета к Луне. Думаю что-то изобразил и спел бы. Ну, (из последнего) типа типа пения Канье Уэста про "синий лен" :)
ИИ может создавать (сам того не понимая, конечно) даже новые алгоритмы. Это заложено в его основу по умолчанию. И как это получается можно доказать даже чисто математически. И, кстати, очень просто. Например, на примере, Вы, может, даже удивитесь, простейшего RS-триггера ;).
Вы не просто лежите - Вы размышляете. Если я мыслю, значит, я живу. Лежит тело, а мысль движется. И, кстати, движение Вашей мысли имитирует некая МТ. Я надеюсь, что именно так ;)
Тут я с Вами не согласен. Данные нельзя имитировать. Имитировать можно какую-то деятельность. Это-то как раз и поясняет МТ. Она создает данные на ленте и имитирует деятельность по их получению. Так и ИИ. Он имитирует деятельность мозга по созданию данных. И этот процесс можно описать машиной Тьюринга. Даже, как ни удивительно, одной. Просто она будет очень большая. Ну, очень! :)
Можно лишь сказать, что есть такая главная машина. Это сам наш мозг. Проблема одна - понять алгоритм ее работы. Так что по большому счету Вы на верном пути. :)
Что такое мозг мы, к сожалению, еще не разобрались. Какую-то его деятельность мы можем сымитировать (тот же ИИ), но и не более того. Машина Тьюринга объясняет наше текущее понимание алгоритма. Но это совсем не про сам алгоритм работы нашего мозга. Ищем, ищем... Но найдем ли и когда? ;) Как-то так.
"Сама по себе" - неправильное и даже вредное мнение. Это следствие вашего ограниченного представления о ней. МТ демонстрирует возможности другого варианта реализации вычислительного процесса. В этом ее "вечная" ценность, которую ни чем не умалить. Она не "сферический конь" в "вакууме извращенного программистского мышления", к чему Вы явно клоните...
Я в статье специально для Вас (и тех кто имеет аналогичное мнение) выделю строку, которую Вы не поняли или осознанно или нет проигнорировали.
Если я правильно понял вопрос, то дело, конечно, совсем не в машине Тьюринга, а в извечном желании человека в чем-то выделиться или что-то доказать. В данном случае протестировать свои алгоритмические способность и доказать/показать как в рамках весьма ограниченных возможностей реализовать не такие уж простые алгоритмические задачи.
Я, наверное, все же дополню статью примером из книги Н.Вирта о нахождении НОД. В рамках обычных возможностей решить данную задачу - почти тьфу, а вот в рамках МТ - это почти проблема. Хотя и решаемая. Вот и ставится задача решить явно решаемое в рамках возможностей, которые переводят решение в разряд почти проблемы. Вот потому и "пинают", как Вы говорите ;)
Как вышеизложенное можно применить для конкретного решения задачи о философах (см. https://habr.com/ru/articles/969036/) и какие результаты/оценки при этом можно получить?
В том-то и дело, что применить этот закон к чему-то просто невозможно. Потому как он не отвечает на вопрос, как посчитать проценты. А с остальным согласен на все "сто".
Все может быть. Может быть любой цвет. Например, переход из состояния 1 в 2 (см. рис.2) может происходить через промежуточное состояние, в котором можно будет включить на какое-то время желтый.
Но это будет уже другой светофор. У рассматриваемого светофора даже не предусмотрен желтый.
А по поводу модели Харелла. Конечно, нет.
Но главная цель статьи в другом. В демонстрации теоретических возможностей автоматов. Есть даже результат, на который следовало бы обратить внимание. Возможностей, которых фактически нет у других моделей. У модели блок-схем (типичной модели для любого языка программирования) так точно. Правда, любую блок-схему можно обратить в автомат и далее продолжить... И, может, если постараться, получить такой же результат. Но можно доказать и обратное. Т.е. у автоматов есть теория, которой можно пользоваться и на формальном уровне делать формальный анализ созданной модели.А это намного эффективнее, чем обычное тестирование.
Ну, вот и всё. До свидания, мой читатель! Спасибо за то, что прочитал эту статью!
Как говорится, - не за что!
Тем не менее, что можно сказать после прочтения столь замечательной статьи? И как можно выразить ту степень благодарности, которую испытываешь после ее прочтения?
Весьма поразила описанная мощь теории многопоточного программирования. Хорошо, что автор напомнил, из чего состоят программы. Теперь хотя бы понятно почему «немного» времени процессор уделяет коду программы. Остальное время – что-то типа «черной материи»?
«Теоретическим открытием» для многих будет и то, что команды в программе выполняются друг за другом. Не совсем, правда, ясно как потоки «могут повысить быстродействие и производительность программы»? Но это, может, из-за непонимания различия между «быстродействием» и «производительностью» программ?
О реализации многопоточности. Даже не к чему придраться. А потому-то, ой, как «здорово получилось»?! Но если рассуждать здраво, то потоки работают одновременно и одновременно «бьются» в консоль. И почему тогда не «каша» из символов/слов, а - просто «здорово»? Почему, как сказано далее, в этом случае «проблем нет», а другие случаи требуют синхронизации?
Если так - другое дело. Как-то не врубился сразу. Так что беру свои слова (про один цвет) обратно.
По поводу таймера. Совсем нет проблем. Здесь используется вложенный автомат. Можно и параллельный. Все эти задержки используются в моих примерах на Git. В базовом автоматном классе (LFsaAppl) это методы FCreateDelay и FCreateParDelay.
У Вас специализированное решение, у меня - универсальное, где цвета могут гореть одновременно, есть действия по установке и сбросу действия. У Вас может гореть только один цвет. Это существенное ограничение.
По поводу корректности. Я даже ждал этот вопрос. У меня таймер - вложенный автомат, а потому не нужно контролировать его завершение.
О процедуре. Она приведена в книге С.Баранова "Синтез микропрограммных автоматов". Знать ее очень полезно. Процедура эта не "помогает" писать, а помогать приводить одну модель к другой. Я беру Вашу - блок-схему и получаю свою - автомат. Она объясняет/доказывает, что Ваша программа это по сути тот же автомат и наоборот.
Так что все нормально. Имя свою модель я очень просто создаю управление светофором. В этом случае я не изобретаю таблицу, не создаю программу перебора ее строк. Т.е. ситуация только проще, а не сложнее. Более того автомат имеет плюшки, которых нет у таблицы и программе к ней.
Автомат ни чего не проверяет :) Есть некое представление таблицы переходов автомата и есть интерпретатор этой таблицы. Вот последний берет эту ТП и в соответствии с ней организует работу остальных компонент автоматной программы (АП). Он имеет информацию о текущем состоянии и понимает какие функции (предикаты и действия) относятся к нему, запускает сначала предикаты для определения наличия условия перехода и если оно есть, то запускаются действия этого сработавшего перехода. Да, при этом, если есть переход, устанавливается новое текущее состояние. Это немного отлично от того, что Вы, прошу прощения, нафантазировали.
Компиляция здесь только навредит делу, т.к. автомат не один, а есть на самом деле множество автоматов, называемое сетью. Вы об этом помните?
Было бы неплохо иметь не программный, а аппаратный интерпретатор. Это бы на порядок, а, может, и несколько увеличило бы скорость. Но и сейчас они очень даже неплохая, если сравнивать параллелизм автоматов и потоков. При необходимости синхронизации процессов, автоматы, думаю, потоки сделают ;)
Создавая свое решение следите, чтобы не создать другую модель. Не плодите ошибок подобных МАТЛAБ, Engee и SimInTech. Они пошли по стопам автоматов Харела. Но это уже другая модель, которую по несчастью тоже назвали конечным автоматом.
Сравните мое решение и Ваше. Я Ваши же запросы к таблице оборачиваю в действия и предикаты автомата. Неужели не понятно? Для кого я это делал, елки-моталки? ;)
это всех нервирует.
Можно не обращать внимания... Но людей "нервирует" в двух случаях. По своей глупости или по глупости автора. Всем не угодишь, но понять почему их "нервирует" важно. Вы явно зря наехали на автоматы. Люди занервничали. Еще не поняли почему?
Может, тебе непонятно и ты потому поставил мне минус? Извини, что на ты, но попробую пояснить. Если поймешь, конечно.
Все просто. Очень просто. Все, что работает на современных процессорах "было, есть, и всегда будет алгоритмами". Согласен? И нет такого алгоритма, который бы нельзя было описать/реализовать машиной Тьюринга. Согласен? Следовательно, всегда можно найти машину Тьюринга, которая опишет алгоритм ответа любого известным тебе ИИ. Есть возражения?
Если есть, то - поздравляю! - ты наконец-то опроверг самого Тьюринга. А если еще предъявишь свои аргументы и доказательства, то этот день будет записан в скрижали теории алгоритмов и программирования. И тогда я к тебе буду обращаться только на Вы.
Ты, мой придирчивый читатель, объясни, пожалуйста, за что ты мне поставил "минус"? Мне это очень важно знать.
К счастью я немного понимаю, как работает динамик :). С пионерского возраста. Кажется этому учат даже в школе (но я разобрался самостоятельно). Вот если бы динамик вдруг сам запел, то я бы с Вами согласился.
А вот ИИ может. Нужно только определить ему цель. Ну типа: спой под Высоцкого на тему полета нашего недавнего (крайнего) полета к Луне. Думаю что-то изобразил и спел бы. Ну, (из последнего) типа типа пения Канье Уэста про "синий лен" :)
ИИ может создавать (сам того не понимая, конечно) даже новые алгоритмы. Это заложено в его основу по умолчанию. И как это получается можно доказать даже чисто математически. И, кстати, очень просто. Например, на примере, Вы, может, даже удивитесь, простейшего RS-триггера ;).
Вы не просто лежите - Вы размышляете. Если я мыслю, значит, я живу. Лежит тело, а мысль движется. И, кстати, движение Вашей мысли имитирует некая МТ. Я надеюсь, что именно так ;)
Тут я с Вами не согласен. Данные нельзя имитировать. Имитировать можно какую-то деятельность. Это-то как раз и поясняет МТ. Она создает данные на ленте и имитирует деятельность по их получению. Так и ИИ. Он имитирует деятельность мозга по созданию данных. И этот процесс можно описать машиной Тьюринга. Даже, как ни удивительно, одной. Просто она будет очень большая. Ну, очень! :)
Можно лишь сказать, что есть такая главная машина. Это сам наш мозг. Проблема одна - понять алгоритм ее работы. Так что по большому счету Вы на верном пути. :)
Что такое мозг мы, к сожалению, еще не разобрались. Какую-то его деятельность мы можем сымитировать (тот же ИИ), но и не более того. Машина Тьюринга объясняет наше текущее понимание алгоритма. Но это совсем не про сам алгоритм работы нашего мозга. Ищем, ищем... Но найдем ли и когда? ;) Как-то так.
Похоже сломался model checking :(
"Сама по себе" - неправильное и даже вредное мнение. Это следствие вашего ограниченного представления о ней. МТ демонстрирует возможности другого варианта реализации вычислительного процесса. В этом ее "вечная" ценность, которую ни чем не умалить. Она не "сферический конь" в "вакууме извращенного программистского мышления", к чему Вы явно клоните...
Я в статье специально для Вас (и тех кто имеет аналогичное мнение) выделю строку, которую Вы не поняли или осознанно или нет проигнорировали.
Если я правильно понял вопрос, то дело, конечно, совсем не в машине Тьюринга, а в извечном желании человека в чем-то выделиться или что-то доказать. В данном случае протестировать свои алгоритмические способность и доказать/показать как в рамках весьма ограниченных возможностей реализовать не такие уж простые алгоритмические задачи.
Я, наверное, все же дополню статью примером из книги Н.Вирта о нахождении НОД. В рамках обычных возможностей решить данную задачу - почти тьфу, а вот в рамках МТ - это почти проблема. Хотя и решаемая. Вот и ставится задача решить явно решаемое в рамках возможностей, которые переводят решение в разряд почти проблемы. Вот потому и "пинают", как Вы говорите ;)
Как вышеизложенное можно применить для конкретного решения задачи о философах (см. https://habr.com/ru/articles/969036/) и какие результаты/оценки при этом можно получить?
По случаю прочитал и Вашу статью. Мы с Вами читали и учились фактически на одних книгах :).
Прошу прощения. Поправил.
В том-то и дело, что применить этот закон к чему-то просто невозможно. Потому как он не отвечает на вопрос, как посчитать проценты. А с остальным согласен на все "сто".
Все может быть. Может быть любой цвет. Например, переход из состояния 1 в 2 (см. рис.2) может происходить через промежуточное состояние, в котором можно будет включить на какое-то время желтый.
Но это будет уже другой светофор. У рассматриваемого светофора даже не предусмотрен желтый.
А по поводу модели Харелла. Конечно, нет.
Но главная цель статьи в другом. В демонстрации теоретических возможностей автоматов. Есть даже результат, на который следовало бы обратить внимание. Возможностей, которых фактически нет у других моделей. У модели блок-схем (типичной модели для любого языка программирования) так точно. Правда, любую блок-схему можно обратить в автомат и далее продолжить... И, может, если постараться, получить такой же результат. Но можно доказать и обратное. Т.е. у автоматов есть теория, которой можно пользоваться и на формальном уровне делать формальный анализ созданной модели.А это намного эффективнее, чем обычное тестирование.
Как говорится, - не за что!
Тем не менее, что можно сказать после прочтения столь замечательной статьи? И как можно выразить ту степень благодарности, которую испытываешь после ее прочтения?
Весьма поразила описанная мощь теории многопоточного программирования. Хорошо, что автор напомнил, из чего состоят программы. Теперь хотя бы понятно почему «немного» времени процессор уделяет коду программы. Остальное время – что-то типа «черной материи»?
«Теоретическим открытием» для многих будет и то, что команды в программе выполняются друг за другом. Не совсем, правда, ясно как потоки «могут повысить быстродействие и производительность программы»? Но это, может, из-за непонимания различия между «быстродействием» и «производительностью» программ?
О реализации многопоточности. Даже не к чему придраться. А потому-то, ой, как «здорово получилось»?! Но если рассуждать здраво, то потоки работают одновременно и одновременно «бьются» в консоль. И почему тогда не «каша» из символов/слов, а - просто «здорово»? Почему, как сказано далее, в этом случае «проблем нет», а другие случаи требуют синхронизации?
С нетерпением ждем разъяснений…
Если так - другое дело. Как-то не врубился сразу. Так что беру свои слова (про один цвет) обратно.
По поводу таймера. Совсем нет проблем. Здесь используется вложенный автомат. Можно и параллельный. Все эти задержки используются в моих примерах на Git. В базовом автоматном классе (LFsaAppl) это методы FCreateDelay и FCreateParDelay.
У Вас специализированное решение, у меня - универсальное, где цвета могут гореть одновременно, есть действия по установке и сбросу действия. У Вас может гореть только один цвет. Это существенное ограничение.
По поводу корректности. Я даже ждал этот вопрос. У меня таймер - вложенный автомат, а потому не нужно контролировать его завершение.
О процедуре. Она приведена в книге С.Баранова "Синтез микропрограммных автоматов". Знать ее очень полезно. Процедура эта не "помогает" писать, а помогать приводить одну модель к другой. Я беру Вашу - блок-схему и получаю свою - автомат. Она объясняет/доказывает, что Ваша программа это по сути тот же автомат и наоборот.
Так что все нормально. Имя свою модель я очень просто создаю управление светофором. В этом случае я не изобретаю таблицу, не создаю программу перебора ее строк. Т.е. ситуация только проще, а не сложнее. Более того автомат имеет плюшки, которых нет у таблицы и программе к ней.
Автомат ни чего не проверяет :) Есть некое представление таблицы переходов автомата и есть интерпретатор этой таблицы. Вот последний берет эту ТП и в соответствии с ней организует работу остальных компонент автоматной программы (АП). Он имеет информацию о текущем состоянии и понимает какие функции (предикаты и действия) относятся к нему, запускает сначала предикаты для определения наличия условия перехода и если оно есть, то запускаются действия этого сработавшего перехода. Да, при этом, если есть переход, устанавливается новое текущее состояние. Это немного отлично от того, что Вы, прошу прощения, нафантазировали.
Компиляция здесь только навредит делу, т.к. автомат не один, а есть на самом деле множество автоматов, называемое сетью. Вы об этом помните?
Было бы неплохо иметь не программный, а аппаратный интерпретатор. Это бы на порядок, а, может, и несколько увеличило бы скорость. Но и сейчас они очень даже неплохая, если сравнивать параллелизм автоматов и потоков. При необходимости синхронизации процессов, автоматы, думаю, потоки сделают ;)
Создавая свое решение следите, чтобы не создать другую модель. Не плодите ошибок подобных МАТЛAБ, Engee и SimInTech. Они пошли по стопам автоматов Харела. Но это уже другая модель, которую по несчастью тоже назвали конечным автоматом.
Сравните мое решение и Ваше. Я Ваши же запросы к таблице оборачиваю в действия и предикаты автомата. Неужели не понятно? Для кого я это делал, елки-моталки? ;)
Можно не обращать внимания... Но людей "нервирует" в двух случаях. По своей глупости или по глупости автора. Всем не угодишь, но понять почему их "нервирует" важно. Вы явно зря наехали на автоматы. Люди занервничали. Еще не поняли почему?