S>>>>Потому что вычисления аргументов для очередного вызова завязаны на результат предыдущих вызовов.
DG>>>это хорошо или плохо? S>>Шуруповерт — это хорошо или плохо? Я так думаю, что шуруповертом хорошо заворачивать шурупы. А чистить уши — плохо. Вот и композиция функций — это инструмент.
DG>ты же по специальности программист? верно?
Нет. Математик.
DG>при этом получается, что ты смог дать наивное пояснение про шуруповерт (который к программированию не имеет никакого отношения) — для каких задач шуруповерт является хорошим инструментом, а для каких не очень (правда скорее всего это опять же не твое понимание, а лишь цитата какого-нибудь авторитета из инструкции к шуруповерту).
DG>а по своей специальности, ты не смог сформулировать даже наивное пояснение, чем хороши (или плохи) завязки между вызовами функциями и при каких условиях. Это к теме, кого сейчас берут в программисты..
Я не знаю, кто ты по специальности, но твои наивные пояснения отношения используемых тобой терминов к общепринятым меня не устраивают. Выдавать тебе такую же бурду в отношении композиции функций я не собираюсь.
Здравствуйте, DarkGray, Вы писали:
S>>>>Возникает вопрос о целеобразности такого автомата, ну да фиг с ним.
DG>>>о том и речь, что все зависит от набора команд, поддержанных исполнительным механизмом (или что тоже самое, от вида исполнителя). S>>Не понимаю, что такое вид исполнителя и как он меняется от изменения набора команд.
DG>есть вид исполнителя: процессор x86, DG>есть вид исполнителя: реляционная субд с поддержкой sql, DG>есть вид исполнителя: стековая машина с модулем АЛУ и ФПУ, DG>есть вид исполнителя: .net, DG>есть вид исполнителя: .net с набором библиотек для заданной тематики, DG>есть вид исполнителя: haskell, DG>есть вид исполнителя: "человек с тремя классами образования", DG>есть вид исполнителя: человек-специалист в заданной тематике. DG>и т.д.
Т.е. виды исполнителей отличаются наименованием что ли?
DG>каждый из них обладает своим набором поддерживаемых команд, если этот набор последовательно менять (добавляя/убавляя по команде), то произойдет переход к другому виду исполнителя.
Это какая-то магия
DG>>>и что если не зафиксирован исполнитель (в виде поддержанного им набора команд), то делать какие-то утверждения бессмысленно, и уж тем более бессмысленно делать заявления о декларативности или императивности управляющего языка. S>>И все-таки, как связана декларативность языка с исполнителем?
DG>напрямую (и ты это увидишь, как только определение из той же вики переведешь к математическому виду)
Ты его уже привел? Можно взглянуть?
DG>например, для исполнителя samius конструкция "автомат из одной команды Z" есть императивная программа, которую он понимает только если рядом приложена пошаговая инструкция, как из этой конструкции перейти к поддерживаемому им набору команд, в частности, к автомату математическому классическому.
Я не понял, что ты написал
DG>большая часть сказанного в треде воспринимается также императивно: понятно пока есть инструкция — как это понимать; при наличии малейших отклонений в условии — ступор и выдача ошибки.
Большую часть сказанного тобой в этом треде я по-началу пытался воспринимать, теперь уже скорее нет, чем да. Я лишь занимаюсь тем, что тыкаю тебя в определения. Какой смысл пытаться что-то понимать, если ты используешь другую терминологию? Ты ведь так и не ответил. Так что я продолжаю развлекаться.
DG>не делает видимых попыток перехода к декларативному мышлению: фиксирование требований к результату с последующим выбором наилучших инструментов для достижения поставленной цели.
Декларативное мышление?
Теперь начинаю понимать
Здравствуйте, gandjustas, Вы писали: G>А толку?
Ну, парни тут явно считают программу "найди такой целый x, чтобы x^3 был равен сумме y^3+z^3, где z и y — целые" императивной. Лишь бы исполнитель был подходящий.
Думаю, дальше смысла обсуждать нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>автомат с двумя выходными лентами — это и есть структурный автомат, состоящий, например, из трех элементарных автоматов
S>Теорию автоматов нам читали, но автомат с двумя выходными лентами я что-то не припомню. Может и просто запамятовал. Но склоняюсь к тому что выдумал его ты.
так и не надо его припоминать, это все равно что припоминать сколько будет 238 * 174. Необходимо уметь строить произвольный автомат с заданными свойствами под конкретную задачу на основе элементарных автоматов.
V>>>>>Просто оно в общем случае описывает эквивалентный автомат, например в терминах use-case... или различные виды описаний каких-нить протоколов и т.д. G>>>>Протокол и есть автомат Но это не ТЗ. Вот ТЗ: "стул должен стоять не ближе 5 метров от дивана". Переведи это в автомат.
DG>>>автомат из одной императивной команды: DG>>>установить положение стула не ближе 5 метров от дивана.
G>>А толку?
DG>при наличии исполнителя, который умеет выполнять эту команду — такого автомата достаточно.
Ключевое слово "подходящий". Сразу понятно что не любой, так как постановка задачи не предполагает конкретного порядка исполнения. Это и есть декларативность.
Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором.
G>Ключевое слово "подходящий". Сразу понятно что не любой, так как постановка задачи не предполагает конкретного порядка исполнения. Это и есть декларативность.
не существует общего алгоритма для измерения "в задаче задан порядок исполнения или не задан".
а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна.
есть лишь субьективные мнения, которые могут быть различны и зависят лишь от личных предпочтений.
G>Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором.
вот ты сейчас предлагаешь уже конструктивное определение для понятия "императивный стиль" (и кстати в этом утверждении уже появился конкретный исполнитель), которое уже как-то измеримо.
тогда появляется система утверждений:
у1. для всякой императивной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора x86 за предсказуемое время с потреблением предсказуемого кол-ва ресурсов.
у2. не для всякой декларативной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора (и далее по тексту)
что даем нам индикатор:
у3. если для программы известен алгоритм, позволяющий выполнить ее с помощью процессора x86, то с большей вероятностью, она принадлежит к классу императивных программ.
вопросы:
в1. классификация декларативная/императивная используется
двузначная (всякая программа обязана принадлежать ровно к одному классу: декларативная/императивная),
трехзначная (всякая программа обязана принадлежать ровно к одному классу: декларативная/императивная/неизвестно),
четырехзначная (всякая программа обязана принадлежать ровно к одному классу: только декларативная/только императивная/неизвестно/и декларативная, и императивная одновременно)
в2. является ли пункт у1 достаточным, чтобы программу отнести к классу императивный?
в3. является ли пункт у1 необходимым, чтобы программу отнести к классу императивный?
G>>А толку? S>Ну, парни тут явно считают программу "найди такой целый x, чтобы x^3 был равен сумме y^3+z^3, где z и y — целые" императивной. Лишь бы исполнитель был подходящий. S>Думаю, дальше смысла обсуждать нет.
samius не смог ответить — спрошу тебя.
какие выводы можно сделать из утверждения: программа "найди такой целый x, чтобы x^3 был равен сумме y^3+z^3, где z и y — целые" — является декларативной?
или другими словами: отнесение программы к декларативной или императивной, это есть задача классификации, а всякая нетривиальная классификация обладает следствием: у каждого класса есть свои свойства, которые не проявляются у других классов.
соответственно, вопрос: после того, как ты отнес программу "найди такой целый x, чтобы x^3 был равен сумме y^3+z^3, где z и y — целые" к классу декларативная, какие свойства у данной программы появились? (вопрос в конструктивной логике, а не в логике существования)
G>>Ключевое слово "подходящий". Сразу понятно что не любой, так как постановка задачи не предполагает конкретного порядка исполнения. Это и есть декларативность.
DG>не существует общего алгоритма для измерения "в задаче задан порядок исполнения или не задан".
Да, поэтому понятие императивности связано с используемым языком описания.
DG>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна.
Для конкретного языка вполне можно утверждать. Например для русского.
G>>Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором. DG>вот ты сейчас предлагаешь уже конструктивное определение для понятия "императивный стиль" (и кстати в этом утверждении уже появился конкретный исполнитель), которое уже как-то измеримо.
Исполнителя заметь ты выдумал. Хотя для любого ТЗ (алгоритма) есть исполнитель.
DG>тогда появляется система утверждений: DG>у1. для всякой императивной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора x86 за предсказуемое время с потреблением предсказуемого кол-ва ресурсов. DG>у2. не для всякой декларативной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора (и далее по тексту)
Без рассмотрения языка смысла не имеет. Как выполнить императивный алгоритм на русском языке с помощью процессора x86?
1) Подойди к стулу
2) Подними стул
3) Если ты стоишь дальше 5 метров от дивана, то подойди к дивану, если ближе, то отойди.
4) Поставь стул
DG>что даем нам индикатор: DG>у3. если для программы известен алгоритм, позволяющий выполнить ее с помощью процессора x86, то с большей вероятностью, она принадлежит к классу императивных программ.
Мощность языков программирования по тьюрингу одинакова и они все выполняются на x86 процессорах. Так что фраза твоя ни о чем.
Еще раз: императивность свойство записи алгоритма. Программа на C будет императивна, а на хаскеле декларативна, а обе считают числа фибоначчи.
Здравствуйте, DarkGray, Вы писали:
G>>Ключевое слово "подходящий". Сразу понятно что не любой, так как постановка задачи не предполагает конкретного порядка исполнения. Это и есть декларативность.
DG>не существует общего алгоритма для измерения "в задаче задан порядок исполнения или не задан".
Это ты намекаешь на жесткость порядка вызова для композиции функций? Его нет. Можно начать со внешней функции, можно со внутренней.
DG>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна.
Алгоритм? Есть определение. Открой его для себя наконец.
G>>Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором.
DG>вот ты сейчас предлагаешь уже конструктивное определение для понятия "императивный стиль" (и кстати в этом утверждении уже появился конкретный исполнитель), которое уже как-то измеримо.
DG>тогда появляется система утверждений: DG>у1. для всякой императивной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора x86 за предсказуемое время с потреблением предсказуемого кол-ва ресурсов.
int x = 1;
for (;;)
{
x = -x;
}
Надо полагать что програма выше не императивна, или таки известен алгоритм, который позволит выполнить ее с помощью x86 за предсказуемое время?
Какую же ты чушь выдумываешь
DG>>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна. G>Для конкретного языка вполне можно утверждать. Например для русского.
приведи алгоритм, как для программы на русском языке измерить относится она к классу: декларативная или императивная?
G>>>Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором. DG>>вот ты сейчас предлагаешь уже конструктивное определение для понятия "императивный стиль" (и кстати в этом утверждении уже появился конкретный исполнитель), которое уже как-то измеримо. G>Исполнителя заметь ты выдумал. Хотя для любого ТЗ (алгоритма) есть исполнитель.
одно с другими не стыкуется. двумя строчками выше в твоей фразе написано слово "исполнитель". оно туда случайно попало?
DG>>тогда появляется система утверждений: DG>>у1. для всякой императивной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора x86 за предсказуемое время с потреблением предсказуемого кол-ва ресурсов. DG>>у2. не для всякой декларативной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора (и далее по тексту) G>Без рассмотрения языка смысла не имеет. Как выполнить императивный алгоритм на русском языке с помощью процессора x86? G>1) Подойди к стулу G>2) Подними стул G>3) Если ты стоишь дальше 5 метров от дивана, то подойди к дивану, если ближе, то отойди. G>4) Поставь стул
например, взять алгоритм которые русские слова переводит в слова языка python.
Проблема может быть с понятиями (а не словами), вернее даже с распознаванием образов (как распознать, какой объект реального мира соответствует понятию "стул"?) — и соответственно всё упрется в исполнителя (умеет он или нет выделять объекты стул и диван из окружающего мира), при этом если утверждается, что умеет, потому что на каждый стул и диван приклеена бирка с поясняющим штрихкодом (или может речь вообще про растановку мебели внутри виртуальной комнаты), то эту программу осилит и процессов x86.
DG>>что даем нам индикатор: DG>>у3. если для программы известен алгоритм, позволяющий выполнить ее с помощью процессора x86, то с большей вероятностью, она принадлежит к классу императивных программ. G>Мощность языков программирования по тьюрингу одинакова и они все выполняются на x86 процессорах. Так что фраза твоя ни о чем.
эта эквивалентность не обещает, что алгоритм после преобразования останется вычислимым за заданное время.
например, склейка двух списков, которая для исполнителя с произвольным доступом к памяти занимает O(1), для исполнителя — чистое ФЯ без ленивости — O(N), для МТ-исполнителя — уже будет O(N^2).
соответственно, если есть алгоритм для списков, который требует N операций склейки списков, для первого случая даст O(N), для второго O(N^2), а для третьего O(N^3)
первый исполнитель может применять такой алгоритм примерно до N=10^12, второй до N=10^6, третий до N=10^4
в итоге, на практике на разных исполнителях за заданное время можно решить разные наборы задач.
G> Программа на C будет императивна, а на хаскеле декларативна, а обе считают числа фибоначчи.
какое это дает различие?
следует ли из этого, например, что компилятору C запрещается на основе своей версии программы заменять расчет числа фибоначчи на конечное число?
DG>>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна. S>Алгоритм? Есть определение. Открой его для себя наконец.
не всякое определение является конструктивным, или другими словами не всякое определение эквивалентно алгоритму.
определение декларативности не является конструктивным (и не имеет эквивалентного алгоритма для отнесения конкретной программы, конкретного языка к декларативным или нет).
S>Надо полагать что програма выше не императивна, или таки известен алгоритм, который позволит выполнить ее с помощью x86 за предсказуемое время?
какие следствия хочется получить от классификации бессмысленных программ — это уже отдельный вопрос.
DG>>>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна. G>>Для конкретного языка вполне можно утверждать. Например для русского.
DG>приведи алгоритм, как для программы на русском языке измерить относится она к классу: декларативная или императивная?
Декларативная не содержит последовательности действия для завершения результата, а только описание самого результата.
G>>>>Программа в императивном стиле может быть исполнена самым тупым исполнителем, например процессором. DG>>>вот ты сейчас предлагаешь уже конструктивное определение для понятия "императивный стиль" (и кстати в этом утверждении уже появился конкретный исполнитель), которое уже как-то измеримо. G>>Исполнителя заметь ты выдумал. Хотя для любого ТЗ (алгоритма) есть исполнитель.
DG>одно с другими не стыкуется. двумя строчками выше в твоей фразе написано слово "исполнитель". оно туда случайно попало?
Это ты его написал
DG>>автомат из одной императивной команды:
DG>>установить положение стула не ближе 5 метров от дивана.
G>А толку?
при наличии исполнителя, который умеет выполнять эту команду — такого автомата достаточно.
DG>>>тогда появляется система утверждений: DG>>>у1. для всякой императивной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора x86 за предсказуемое время с потреблением предсказуемого кол-ва ресурсов. DG>>>у2. не для всякой декларативной программы известен алгоритм, который позволяет эту программу выполнить с помощью процессора (и далее по тексту) G>>Без рассмотрения языка смысла не имеет. Как выполнить императивный алгоритм на русском языке с помощью процессора x86? G>>1) Подойди к стулу G>>2) Подними стул G>>3) Если ты стоишь дальше 5 метров от дивана, то подойди к дивану, если ближе, то отойди. G>>4) Поставь стул
DG>например, взять алгоритм которые русские слова переводит в слова языка python.
И? От этого стул окажется на расстоянии 5 метров от дивана?
DG>Проблема может быть с понятиями (а не словами), вернее даже с распознаванием образов (как распознать, какой объект реального мира соответствует понятию "стул"?) — и соответственно всё упрется в исполнителя (умеет он или нет выделять объекты стул и диван из окружающего мира), при этом если утверждается, что умеет, потому что на каждый стул и диван приклеена бирка с поясняющим штрихкодом (или может речь вообще про растановку мебели внутри виртуальной комнаты), то эту программу осилит и процессов x86.
Напиши проще: понимает ли исполнитель язык. Я тебе об этом и толкую, что без языка нет смысла обсуждать. И совершенно необязательно это должен быть формальный язык или машинный язык.
DG>>>что даем нам индикатор: DG>>>у3. если для программы известен алгоритм, позволяющий выполнить ее с помощью процессора x86, то с большей вероятностью, она принадлежит к классу императивных программ. G>>Мощность языков программирования по тьюрингу одинакова и они все выполняются на x86 процессорах. Так что фраза твоя ни о чем.
DG>эта эквивалентность не обещает, что алгоритм после преобразования останется вычислимым за заданное время.
А причем тут время? Мы про время еще ничего не говорили. Не надо лишние, для понимания сути, вещи включать.
DG>например, склейка двух списков, которая для исполнителя с произвольным доступом к памяти занимает O(1), для исполнителя — чистое ФЯ без ленивости — O(N), для МТ-исполнителя — уже будет O(N^2).
Это свойство исполнителя, но причем тут декларативность\императивность? Они от исполнителя не зависят, они от языка зависят.
G>> Программа на C будет императивна, а на хаскеле декларативна, а обе считают числа фибоначчи. DG>какое это дает различие?
Различие в том что прогармма на C выглядит как последовательность шагов для вычисления нужного числа, программа на haskell больше похожа на математическое определение.
Естественно с точи зрения дальнейшего анализа и рассуждения над программой лучше иметь декларативный код, так как он ближе к ТЗ.
G>Напиши проще: понимает ли исполнитель язык. Я тебе об этом и толкую, что без языка нет смысла обсуждать. И совершенно необязательно это должен быть формальный язык или машинный язык.
что такое "понимает язык"? процессор x86 язык C понимает или не понимает? это не конструктивное определение, а опять же вкусовщина.
конструктивное определение — исполнитель Z поддерживает язык L, если существует алгоритм, который переводит язык L в набор команд поддерживаемый исполнителем Z.
DG>эта эквивалентность не обещает, что алгоритм после преобразования останется вычислимым за заданное время. G> А причем тут время? Мы про время еще ничего не говорили. Не надо лишние, для понимания сути, вещи включать.
если не брать время, то из эквивалентности языка C и языка haskell следует, что программу на языке C можно автоматически перевести на язык haskell, и соответственно любую императивную программу на языке C можно автоматически представить в декларативном виде.
DG>>>а раз нет алгоритма, то и не существует объективного способа утверждать данная конструкция декларативна или императивна. S>>Алгоритм? Есть определение. Открой его для себя наконец.
DG>не всякое определение является конструктивным, или другими словами не всякое определение эквивалентно алгоритму. DG>определение декларативности не является конструктивным (и не имеет эквивалентного алгоритма для отнесения конкретной программы, конкретного языка к декларативным или нет).
Сходи по ссылке на определение. Увидь в нем ссылку на поток управления. Прочитай о потоке управления. Поищи признаки потока управления в программе. Если найдешь — значит императив.
Так достаточно императивно для тебя? Нужно ли писать инструкции для узнавания конструкций потока управления?
S>>Надо полагать что програма выше не императивна, или таки известен алгоритм, который позволит выполнить ее с помощью x86 за предсказуемое время?
DG>какие следствия хочется получить от классификации бессмысленных программ — это уже отдельный вопрос.
Отчего бессмысленных? Ее смысл заключается в том, что бы показать что твое утверждение чушь. Во всяком случае смысла в ней не меньше, чем в твоей последней.
Могу написать императивную программу со смыслом, которая за конечное время x86 не выполнится. От этого ведь ничего не изменится. Твое утверждение останется чушью. Так что вопрос классификации бессмысленных программ можно не отделять.
Здравствуйте, DarkGray, Вы писали:
G>>Напиши проще: понимает ли исполнитель язык. Я тебе об этом и толкую, что без языка нет смысла обсуждать. И совершенно необязательно это должен быть формальный язык или машинный язык.
DG>что такое "понимает язык"? процессор x86 язык C понимает или не понимает? это не конструктивное определение, а опять же вкусовщина. DG>конструктивное определение — исполнитель Z поддерживает язык L, если существует алгоритм, который переводит язык L в набор команд поддерживаемый исполнителем Z.
Следующим шагом будет то, что декларативные программы, это те, для которых не существует алгоритма перевода в язык MT?
DG>>эта эквивалентность не обещает, что алгоритм после преобразования останется вычислимым за заданное время. G>> А причем тут время? Мы про время еще ничего не говорили. Не надо лишние, для понимания сути, вещи включать.
DG>если не брать время, то из эквивалентности языка C и языка haskell следует, что программу на языке C можно автоматически перевести на язык haskell, и соответственно любую императивную программу на языке C можно автоматически представить в декларативном виде.
Мутишь воду. Равная мощность языков по Тьюрингу не означает возможность автоматического перевода. Определение читал?
S>>Так достаточно императивно для тебя? Нужно ли писать инструкции для узнавания конструкций потока управления?
DG>напиши, пожалуйста. DG> сразу с алгоритмом, как отличать императивный аналог из C от декларативного аналога из haskell.
Напиши мне тогда, что является аналогом перехода в хаскеле, условного перехода, аналогом цикла, halt-а и т.п.
Здравствуйте, DarkGray, Вы писали:
G>>Напиши проще: понимает ли исполнитель язык. Я тебе об этом и толкую, что без языка нет смысла обсуждать. И совершенно необязательно это должен быть формальный язык или машинный язык.
DG>что такое "понимает язык"?
То есть для него предложение на языке не является бессвязным набором символов.
DG>процессор x86 язык C понимает или не понимает?
Не понимает, но понимает копилятор, а так как язык формален, то есть однозначное отображение на x86.
Можешь считать что понимает. А вот русский язык не понимает.
Но это никак не относится к императивности и декларативности.
DG>это не конструктивное определение, а опять же вкусовщина. DG>конструктивное определение — исполнитель Z поддерживает язык L, если существует алгоритм, который переводит язык L в набор команд поддерживаемый исполнителем Z.
Это ты придумал исполнителя и начал все усложнять. Я же говорю тебе что не стоит.
DG>>эта эквивалентность не обещает, что алгоритм после преобразования останется вычислимым за заданное время. G>> А причем тут время? Мы про время еще ничего не говорили. Не надо лишние, для понимания сути, вещи включать.
DG>если не брать время, то из эквивалентности языка C и языка haskell следует, что программу на языке C можно автоматически перевести на язык haskell, и соответственно любую императивную программу на языке C можно автоматически представить в декларативном виде.
Не получится, программа на C содержит слишком мало сведений чтобы сделать её декларативной автоматически. А вот наоборот — вполне. Более того императивную программу на haskell (завернутое в IO) не получится автоматически переписать в декларативную программу на haskell.
S>Мутишь воду. Равная мощность языков по Тьюрингу не означает возможность автоматического перевода. Определение читал?
если не требуется сохранить время выполнения, то означает.
для перевода языка L1 в язык L2 без сохранения времени выполнения программы достаточно:
1. на языке L2 иметь компилируемый эмулятор языка L3 стековой машины (или, например, эмулятор asm x86),
2. иметь транслятор с языка L1 на язык L3 стековой машины(или, например, asm x86)
программа на языке L1 транслятором переводится в листинг L3, который переводится в листинг языка L1.
Но это не ТЗ. Вот ТЗ: "стул должен стоять не ближе 5 метров от дивана". Переведи это в автомат.
