DG>возьмем запись "1 + 2 * 3", ее можно специфицировать через вычислитель (стековую машину), можно через правила математики, можно еще стопятнадцатью способов. и во всех этих случаях результат будет получаться один и тот же. будет меняться только запись способа того, как результат получается.
Ну, во-первых, не во всех. Мы можем придать ей императивную семантику таким образом, что 2 * 3 будет означать "format C:". Не читая спецификацию, проверить это нельзя.
DG>если учесть, что сейчас во всю используется подход, что в ФЯ, что в ООП, что в других парадигмах — что неизменным должен оставаться только наблюдаемый результат, то получается что все спецификации, который специфицирует один и тот же результат для одной и той же записи, а отличаются лишь способами расчета — одинаковые, и соответственно раздел "как" спецификации становится неважным, он лишь необходим чтобы можно было восстановить спецификацию результата.
Во-вторых то, что некоторые императивные программы внешне похожи на декларативные, ничего не означает. Например, на стандартной клавиатуре латинская C и кириллическая С расположены на одной и той же кнопке. Говорит ли это о том, что латиницу и кириллицу можно считать одинаковами?
Теперь вернёмся к спецификациям. Чтобы спецификации они были одинаковыми, недостаточно того, чтобы они приводили к одинаковым результатам для какой-то одной программы. Нужно, чтобы они приводили к одинаковым результатам для любой программы. Так что все разделы спецификации внезапно оказываются важными.
Но всё это — бессмысленное обсуждение. Вы опять пытаетесь классифицировать декларативные и императивные программы на основе признаков, которые не дают корректных результатов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ну, во-первых, не во всех. Мы можем придать ей императивную семантику таким образом, что 2 * 3 будет означать "format C:". Не читая спецификацию, проверить это нельзя.
можем. но при этом достаточно читать спецификацию результата, спецификацию вычислителя можно не читать.
или если нет спецификации результата, то можно прочитать спецификацию вычислителя — восстановить спецификацию результата, а спецификацию вычислителя выкинуть, и получать специфицированный результат как хочется.
S>Во-вторых то, что некоторые императивные программы внешне похожи на декларативные, ничего не означает. Например, на стандартной клавиатуре латинская C и кириллическая С расположены на одной и той же кнопке. Говорит ли это о том, что латиницу и кириллицу можно считать одинаковами?
что в этом примере является результатом?
S>Теперь вернёмся к спецификациям. Чтобы спецификации они были одинаковыми, недостаточно того, чтобы они приводили к одинаковым результатам для какой-то одной программы.
S> Нужно, чтобы они приводили к одинаковым результатам для любой программы. Так что все разделы спецификации внезапно оказываются важными.
реальным людям необходимы одинаковые результаты в один в один на много меньшем подмножестве программ, а именно на подмножестве осмысленных и корректных программ.
и этим же реальным людям для неосмысленных и некорректных программ достаточно того, что тем или иным способом возвращается ошибка (одинаковость fail-а уже никто и не ожидает)
90% спецификации (если не 99%) обычно специфицируют результат для некорректных или вырожденных случаев. при этом в реальной программе это всё не используется, а значит не влияет на результат и может быть выброшено.
Здравствуйте, DarkGray, Вы писали: DG>можем. но при этом достаточно читать спецификацию результата, спецификацию вычислителя можно не читать.
Откуда возьмётся "спецификация результата"?
DG>или если нет спецификации результата, то можно прочитать спецификацию вычислителя — восстановить спецификацию результата, а спецификацию вычислителя выкинуть, и получать специфицированный результат как хочется.
Очень хорошо. Для некоторого класса программ — вроде приведённого вами, задача тривиальна. Просто вычисляем-вычисляем, в конце получаем 7 и больше нам ничего считать не надо.
Давайте возьмём пример поинтереснее.
IEnumerable<int> F(IEnumerable<int> source)
{
foreach(var i in source)
{
_a = i ^ (i << (_a &&0x4)) ^ (i >> 16));
yield return i ^ _a;
}
}
private int _a = 42;
Вас не затруднит восстановить спецификацию результата, чтобы мы могли спокойно выкинуть спецификацию вычислителя?
DG>90% спецификации (если не 99%) обычно специфицируют результат для некорректных или вырожденных случаев. при этом в реальной программе это всё не используется, а значит не влияет на результат и может быть выброшено.
Ну и что же из этого следует?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>IEnumerable<int> F(IEnumerable<int> source)
S>{
S> foreach(var i in source)
S> {
S> _a = i ^ (i << (_a &&0x4)) ^ (i >> 16));
S> yield return i ^ _a;
S> }
S>}
S>private int _a = 42;
S>
S>Вас не затруднит восстановить спецификацию результата, чтобы мы могли спокойно выкинуть спецификацию вычислителя?
результат этого кода эквивалентен результату кода
(target, _a) = source.Wave(a:_a, (i, a) =>
{
var di = (i << (a &&0x4)) ^ (i >> 16));
return (di, a:i ^ di);
}
)
wave — это объединение select-а с aggregate/accumulate: обработка каждого значения совмещена с расчетом аккумулятора. и wave эффективно может быть реализован поверх широкого класса вычислителей.
при этом используется, что в реальных программах необходима однозначность значимой части результата, и что одновременно две функции F не исполняются
после такой замены, спецификацию на ienumerable и yield можно выкинуть.
остается только спецификация на операции ^ << >> &&, которая идентичная для большинства языков. за исключением вырожденных случаев.
зы
декларация же может быть задана в виде: результат должен быть таким же, как результат вот такого-то вычисления, а выполнять можете как хотите (и для сложных алгоритмов нет другого способа задания результата)
и возможность такого задания декларации делает тривиальным переход от последовательности вычисления к спецификации результата — достаточно для имеющейся последовательности вычисления сказать: требуется результат, как результат данной программы, а считать можете как хотите.
при этом утверждение "делайте как хотите, главное чтобы результат был тем же самым" и так уже говорится, что для ФЯ, что для ООП и т.д. — что внутреннее поведение неважно, важно чтобы сохранялось внешнее поведение(внешний результат)
DG>>90% спецификации (если не 99%) обычно специфицируют результат для некорректных или вырожденных случаев. при этом в реальной программе это всё не используется, а значит не влияет на результат и может быть выброшено. S>Ну и что же из этого следует?
что две спецификации результата, отличающиеся лишь спецификацией результата для некорректного поведения — для значимой части программ являются одной и той же спецификацией.
S>>IEnumerable<int> F(IEnumerable<int> source)
S>>{
S>> foreach(var i in source)
S>> {
S>> _a = i ^ (i << (_a &&0x4)) ^ (i >> 16));
S>> yield return i ^ _a;
S>> }
S>>}
S>>private int _a = 42;
S>>
S>>Вас не затруднит восстановить спецификацию результата, чтобы мы могли спокойно выкинуть спецификацию вычислителя?
DG>результат этого кода эквивалентен результату кода DG>
DG>(target, _a) = source.Wave(a:_a, (i, a) =>
DG> {
DG> var di = (i << (a &&0x4)) ^ (i >> 16));
DG> return (di, a:i ^ di);
DG> }
DG>)
DG>
DG>wave — это объединение select-а с aggregate/accumulate: обработка каждого значения совмещена с расчетом аккумулятора. и wave эффективно может быть реализован поверх широкого класса вычислителей. DG>при этом используется, что в реальных программах необходима однозначность значимой части результата, и что одновременно две функции F не исполняются
Однозначность значимой части результата — это детерминированность? Если да, то в исходном коде результат недетерминирован, что его отличает от преобразованного. Если нет — что подразумевается под однозначностью значимой части результата?
DG>после такой замены, спецификацию на ienumerable и yield можно выкинуть. DG>остается только спецификация на операции ^ << >> &&, которая идентичная для большинства языков. за исключением вырожденных случаев.
Только нужна спецификация двоеточия, Wave, "скобочек". Мне вот с разбегу не понятно, почему кортеж должен быть эквивалентен IEnumerable.
S>Однозначность значимой части результата — это детерминированность?
зная твою тягу к буквоедству, не готов ничего сказать про детерминированность, пока не будет определения этого термина через более базовые понятия.
однозначность X от Y — при одинаковых значениях Y получаются одинаковые значения X
однозначность реального кода — однозначность значимой части результа относительно значимой части входа и значимых условий выполнения
значимая часть — это та часть, которую мы принимаем во внимание.
S> Если да, то в исходном коде результат недетерминирован, что его отличает от преобразованного.
результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
S> Если нет — что подразумевается под однозначностью значимой части результата?
DG>>после такой замены, спецификацию на ienumerable и yield можно выкинуть. DG>>остается только спецификация на операции ^ << >> &&, которая идентичная для большинства языков. за исключением вырожденных случаев.
S>Только нужна спецификация двоеточия, Wave, "скобочек". Мне вот с разбегу не понятно, почему кортеж должен быть эквивалентен IEnumerable.
есть такая проблема.
и она возникает даже на классическом варианте с сортировкой: когда результат специфицируется проще, чем выполнение.
все равно, чтобы зафиксировать требования к результату сортировки необходимо сначала ввести хоть какого-нибудь исполнителя и операции над ним. чтобы однозначно записать, что такое отсортированная последовательность.
Здравствуйте, DarkGray, Вы писали:
S>>Однозначность значимой части результата — это детерминированность?
DG>зная твою тягу к буквоедству, не готов ничего сказать про детерминированность, пока не будет определения этого термина через более базовые понятия.
Зная твою тягу к называнию каких-то своих понятий общеупотребимыми словами, пытаюсь уточнить о чем речь сразу.
DG>однозначность X от Y — при одинаковых значениях Y получаются одинаковые значения X
А X при этом должен себя вести однозначно? Считается ли по-твоему однозначной зависимость X от того, сколько раз его спросили о чем-то? Должен ли X.First() == X.First()?
DG>однозначность реального кода — однозначность значимой части результа относительно значимой части входа и значимых условий выполнения
DG>значимая часть — это та часть, которую мы принимаем во внимание.
Ты принимаешь во внимание что результирующая последовательность изменяется при обращении к ней?
S>> Если да, то в исходном коде результат недетерминирован, что его отличает от преобразованного.
DG>результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
А что касается (target, _a), будет ли оно однозначной?
S>>Только нужна спецификация двоеточия, Wave, "скобочек". Мне вот с разбегу не понятно, почему кортеж должен быть эквивалентен IEnumerable.
DG>есть такая проблема. DG>и она возникает даже на классическом варианте с сортировкой: когда результат специфицируется проще, чем выполнение. DG>все равно, чтобы зафиксировать требования к результату сортировки необходимо сначала ввести хоть какого-нибудь исполнителя и операции над ним. чтобы однозначно записать, что такое отсортированная последовательность.
Зачем тут исполнитель? Упорядоченность по ключу определяет остортированноую последовательность. Для однозначности можно потребовать устойчивость. Какая разница, какой исполнитель сортировал?
Здравствуйте, samius, Вы писали:
S>Зачем тут исполнитель? Упорядоченность по ключу определяет остортированноую последовательность. Для однозначности можно потребовать устойчивость. Какая разница, какой исполнитель сортировал?
Более того, упорядоченность по ключу задаётся выполнением предиката (i<j) ==> (item[i].Key <= item[j].Key)
При этом нам необязательно предоставлять конкретный алгоритм проверки этого предиката.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>все равно, чтобы зафиксировать требования к результату сортировки необходимо сначала ввести хоть какого-нибудь исполнителя и операции над ним. чтобы однозначно записать, что такое отсортированная последовательность. S>Зачем тут исполнитель? Упорядоченность по ключу определяет остортированноую последовательность. Для однозначности можно потребовать устойчивость. Какая разница, какой исполнитель сортировал?
передергиваешь. я не говорил, что нужен исполнитель для сортировки.
я говорил, что нужен исполнитель для того, чтобы выполнить условие накладываемое на результат сортировки.
однозначная трактовка предиката "каждое следующее неменьше предыдущего" или "для любой пары ti, tj результирующей последовательности при i >= j должно выполняться условие cmp(ti, tj) >= 0" и т.д. — не дана каждому свыше, а значит каждый может трактовать ее по своему. и чтобы все трактовали этот предикат однозначно, необходимо ввести вычислитель и правила вычисления.
и в любой алгебре (логическая алгебра, элементарная алгебра и т.д.) именно это и делается.
DG>>однозначность X от Y — при одинаковых значениях Y получаются одинаковые значения X S>А X при этом должен себя вести однозначно?
однозначно от какого входа?
S> Считается ли по-твоему однозначной зависимость X от того, сколько раз его спросили о чем-то?
не важно, здесь рассматривается уже другой выход относительного другого входа
S> Должен ли X.First() == X.First()?
определенного вывода сделать нельзя. очень много зависит от нюансов.
например, смотря как определена операция равенства для X. например, если X.First() в это сравнение вообще не входит, то на X.First() == X.First() вообще пофигу
S> Ты принимаешь во внимание что результирующая последовательность изменяется при обращении к ней?
значимость этого зависит от того, как определены рассматриваемые вход и выход
DG>результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
SS>А что касается (target, _a), будет ли оно однозначной?
Здравствуйте, DarkGray, Вы писали:
DG>>>все равно, чтобы зафиксировать требования к результату сортировки необходимо сначала ввести хоть какого-нибудь исполнителя и операции над ним. чтобы однозначно записать, что такое отсортированная последовательность. S>>Зачем тут исполнитель? Упорядоченность по ключу определяет остортированноую последовательность. Для однозначности можно потребовать устойчивость. Какая разница, какой исполнитель сортировал?
DG>передергиваешь. я не говорил, что нужен исполнитель для сортировки. DG>я говорил, что нужен исполнитель для того, чтобы выполнить условие накладываемое на результат сортировки.
Что значит выполнить условие? Я понимаю так: есть результат, есть условие, которое либо выполняется, либо нет. Исполнитель может отстортировать, может проверить условие. Но выполнить условие
Лучше вернемся к термину "зафиксировать требования". Так вот, требованиям должна удовлетворять результирующая последовательность. И должна она этим требованиям удовлетворять вне зависимости от исполнителя и от того, как ты эти требования запишешь в коде для конкретного исполнителя. Это если, конечно, тебя интересует результирующая последовательность, а не сам процесс фиксирования требований для конкретного исполнителя.
DG>однозначная трактовка предиката "каждое следующее неменьше предыдущего" или "для любой пары ti, tj результирующей последовательности при i >= j должно выполняться условие cmp(ti, tj) >= 0" и т.д. — не дана каждому свыше, а значит каждый может трактовать ее по своему.
Слушай, термин "порядок" определен однозначно свыше. Только ты трактуешь термины по-своему.
DG>и чтобы все трактовали этот предикат однозначно, необходимо ввести вычислитель и правила вычисления.
Обычно все немного наоборот. Сначала формулируются требования к результату, потом они (либо инструкции по получению результата) записываются в коде для определенного вычислителя согласно его правилам вычисления.
DG>и в любой алгебре (логическая алгебра, элементарная алгебра и т.д.) именно это и делается.
Не так давно ты предлагал отказаться от обсуждения терминов вообще, теперь же хочешь однозначности трактовки.
DG>>>однозначность X от Y — при одинаковых значениях Y получаются одинаковые значения X S>>А X при этом должен себя вести однозначно?
DG>однозначно от какого входа?
От самого себя, например.
S>> Считается ли по-твоему однозначной зависимость X от того, сколько раз его спросили о чем-то?
DG>не важно, здесь рассматривается уже другой выход относительного другого входа
S>> Должен ли X.First() == X.First()?
DG>определенного вывода сделать нельзя. очень много зависит от нюансов. DG>например, смотря как определена операция равенства для X. например, если X.First() в это сравнение вообще не входит, то на X.First() == X.First() вообще пофигу
Речь все еще о примере Синклера с IEnumerable<int>. Вопрос был об однозначности результата той функции F. Будет ли он "однозначным" по твоему (ты же отказался обсуждать детерминированность, а я пытаюсь понять, что ты под однозначностью понимаешь с ньюансами)?
var X = F(new int[]{1, 2, 3});
Console.WriteLine(X.First() == X.First()); // Допускает ли твоя однозначность здесь False?
S>> Ты принимаешь во внимание что результирующая последовательность изменяется при обращении к ней?
DG>значимость этого зависит от того, как определены рассматриваемые вход и выход
См пример Синклера
DG>>результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
SS>>А что касается (target, _a), будет ли оно однозначной?
DG>(target, _a) однозначен от (source, _a)
У чего тут первый член брать? И как проверить, будет ли он равен первому члену, запрошенному еще раз у того же результата?
DG>>передергиваешь. я не говорил, что нужен исполнитель для сортировки. DG>>я говорил, что нужен исполнитель для того, чтобы выполнить условие накладываемое на результат сортировки. S>Что значит выполнить условие? Я понимаю так: есть результат, есть условие, которое либо выполняется, либо нет. Исполнитель может отстортировать, может проверить условие. Но выполнить условие
как ты собираешься проверять условие без выполнения чего-либо?
DG>>однозначная трактовка предиката "каждое следующее неменьше предыдущего" или "для любой пары ti, tj результирующей последовательности при i >= j должно выполняться условие cmp(ti, tj) >= 0" и т.д. — не дана каждому свыше, а значит каждый может трактовать ее по своему. S>Слушай, термин "порядок" определен однозначно свыше. Только ты трактуешь термины по-своему.
никакого свыше нет. "порядок" даже не является аксиоматическим понятием.
DG>>и чтобы все трактовали этот предикат однозначно, необходимо ввести вычислитель и правила вычисления. S>Обычно все немного наоборот. S> Сначала формулируются требования к результату,
в виде алгоритма для абстрактного вычислителя
S> потом они (либо инструкции по получению результата) записываются в коде для определенного вычислителя согласно его правилам вычисления.
потом исходный алгоритм для абстрактного вычислителя преобразуется в алгоритм для определенного вычислителя
DG>>и в любой алгебре (логическая алгебра, элементарная алгебра и т.д.) именно это и делается. S>Не так давно ты предлагал отказаться от обсуждения терминов вообще, теперь же хочешь однозначности трактовки.
я говорил, что фиксировать термины без фиксирования задачи не имеет смысл.
S>Речь все еще о примере Синклера с IEnumerable<int>. Вопрос был об однозначности результата той функции F. Будет ли он "однозначным" по твоему (ты же отказался обсуждать детерминированность, а я пытаюсь понять, что ты под однозначностью понимаешь с ньюансами)?
S>
S>var X = F(new int[]{1, 2, 3});
S>Console.WriteLine(X.First() == X.First()); // Допускает ли твоя однозначность здесь False?
S>
для функции синклера здесь конечно может быть false, как минимум потому что функция F выполняется параллельно, и я специально оговорил, что при параллельном выполнении F однозначности добиться будет трудно. и что поэтому едва ли такое использование функции F можно рассматривать как реальное.
вот такой код, кстати, уже всегда будет true
var source = new int[]{1, 2, 3};
_a = 42;
var X1 = F(source);
var x1_f = X1.First();
_a = 42;
var X2 = F(source);
var x2_f = X2.first();
Console.WriteLine(x1_f == x2_f); // Допускает ли твоя однозначность здесь False?
S>>> Ты принимаешь во внимание что результирующая последовательность изменяется при обращении к ней?
DG>>значимость этого зависит от того, как определены рассматриваемые вход и выход S>См пример Синклера
для нее не оговорено, что есть вход и выход
DG>>>результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
SS>>>А что касается (target, _a), будет ли оно однозначной?
DG>>(target, _a) однозначен от (source, _a) S>У чего тут первый член брать? И как проверить, будет ли он равен первому члену, запрошенному еще раз у того же результата?
брать у target
вызвать один и тот же Wave(..) для одних и тех же (source, _a)
DG>>>передергиваешь. я не говорил, что нужен исполнитель для сортировки. DG>>>я говорил, что нужен исполнитель для того, чтобы выполнить условие накладываемое на результат сортировки. S>>Что значит выполнить условие? Я понимаю так: есть результат, есть условие, которое либо выполняется, либо нет. Исполнитель может отстортировать, может проверить условие. Но выполнить условие
DG>как ты собираешься проверять условие без выполнения чего-либо?
Линейкой. Мерили ведь раньше без выполнения чего-либо.
DG>>>однозначная трактовка предиката "каждое следующее неменьше предыдущего" или "для любой пары ti, tj результирующей последовательности при i >= j должно выполняться условие cmp(ti, tj) >= 0" и т.д. — не дана каждому свыше, а значит каждый может трактовать ее по своему. S>>Слушай, термин "порядок" определен однозначно свыше. Только ты трактуешь термины по-своему.
DG>никакого свыше нет. "порядок" даже не является аксиоматическим понятием.
Аксиоматическим — нет. Но когда клиент говорит что ему нужна упорядоченная последовательность, то возникает вопрос лишь "по какому признаку", а не о том, как трактовать "порядок".
DG>>>и чтобы все трактовали этот предикат однозначно, необходимо ввести вычислитель и правила вычисления. S>>Обычно все немного наоборот. S>> Сначала формулируются требования к результату,
DG>в виде алгоритма для абстрактного вычислителя
Требования к результату могут быть выражены без алгоритма абстрактного вычислителя. Например: по росту. Всё. Где здесь алгоритм? Где вычислитель?
S>> потом они (либо инструкции по получению результата) записываются в коде для определенного вычислителя согласно его правилам вычисления.
DG>потом исходный алгоритм для абстрактного вычислителя преобразуется в алгоритм для определенного вычислителя
Определенный вычислитель может не пользоваться алгоритмами явно.
DG>>>и в любой алгебре (логическая алгебра, элементарная алгебра и т.д.) именно это и делается. S>>Не так давно ты предлагал отказаться от обсуждения терминов вообще, теперь же хочешь однозначности трактовки.
DG>я говорил, что фиксировать термины без фиксирования задачи не имеет смысл.
Если ты их не фиксировал, почему их употребляешь?
S>>Речь все еще о примере Синклера с IEnumerable<int>. Вопрос был об однозначности результата той функции F. Будет ли он "однозначным" по твоему (ты же отказался обсуждать детерминированность, а я пытаюсь понять, что ты под однозначностью понимаешь с ньюансами)?
S>>
S>>var X = F(new int[]{1, 2, 3});
S>>Console.WriteLine(X.First() == X.First()); // Допускает ли твоя однозначность здесь False?
S>>
DG>для функции синклера здесь конечно может быть false, как минимум потому что функция F выполняется параллельно, и я специально оговорил, что при параллельном выполнении F однозначности добиться будет трудно. и что поэтому едва ли такое использование функции F можно рассматривать как реальное.
Никаких параллельно. Что ты вообще подразумеваешь под параллельно? Многозадачность? Ее здесь нет.
DG>вот такой код, кстати, уже всегда будет true
DG>
А кто будет сбрасывать _a в начальное состояние в примере Синклера?
DG>>>значимость этого зависит от того, как определены рассматриваемые вход и выход S>>См пример Синклера
DG>для нее не оговорено, что есть вход и выход
И ты при этом не постеснялся заявить что твой код является эквивалентным?
DG>>>>результат исходной функции F однозначен относительно состояния последовательности source и состояния переменной a, при условии что параллельно не выполняются две функции F
SS>>>>А что касается (target, _a), будет ли оно однозначной?
DG>>>(target, _a) однозначен от (source, _a) S>>У чего тут первый член брать? И как проверить, будет ли он равен первому члену, запрошенному еще раз у того же результата?
DG>брать у target DG>вызвать один и тот же Wave(..) для одних и тех же (source, _a)
Ну и о какой эквивалентности речь, если target "однозначен", а результат исходного примера нет?
DG>>для функции синклера здесь конечно может быть false, как минимум потому что функция F выполняется параллельно, и я специально оговорил, что при параллельном выполнении F однозначности добиться будет трудно. и что поэтому едва ли такое использование функции F можно рассматривать как реальное. S>Никаких параллельно. Что ты вообще подразумеваешь под параллельно? Многозадачность? Ее здесь нет.
многозадачности нет, а параллельность есть. строки кода функции F выполняются параллельно в данном примере, это можно, например, увидеть если поставить breakpoint-ы в функцию F. функция F вызовется дважды, при этом второй вызов функции F начнется раньше, чем полностью закончится первый.
S>А кто будет сбрасывать _a в начальное состояние в примере Синклера?
например, строка private int _a = 42 из исходного кода, если пример Синклера будет запускаться как несколько экземпляров программ.
DG>>>>значимость этого зависит от того, как определены рассматриваемые вход и выход S>>>См пример Синклера
DG>>для нее не оговорено, что есть вход и выход S>И ты при этом не постеснялся заявить что твой код является эквивалентным?
я привел условия, при которых я считаю, что данные два кода эквивалентные. привел, конечно, не все условия, а только неочевидные.
DG>>как ты собираешься проверять условие без выполнения чего-либо? S>Линейкой. Мерили ведь раньше без выполнения чего-либо.
чтобы измерить линейкой уже необходим исполнитель в виде человека с инструкцией, что такое линейка, куда ее прикладывать, какой стороной, и на что смотреть.
DG>>никакого свыше нет. "порядок" даже не является аксиоматическим понятием. S>Аксиоматическим — нет. Но когда клиент говорит что ему нужна упорядоченная последовательность, то возникает вопрос лишь "по какому признаку", а не о том, как трактовать "порядок".
это как-то доказывает, что все люди трактуют понятие "упорядоченная последовательность" однозначным способом?
DG>>в виде алгоритма для абстрактного вычислителя S>Требования к результату могут быть выражены без алгоритма абстрактного вычислителя. Например: по росту. Всё. Где здесь алгоритм? Где вычислитель?
что "по росту"?
S>>> потом они (либо инструкции по получению результата) записываются в коде для определенного вычислителя согласно его правилам вычисления.
DG>>потом исходный алгоритм для абстрактного вычислителя преобразуется в алгоритм для определенного вычислителя S>Определенный вычислитель может не пользоваться алгоритмами явно.
пример такого вычислителя
DG>>>>и в любой алгебре (логическая алгебра, элементарная алгебра и т.д.) именно это и делается. S>>>Не так давно ты предлагал отказаться от обсуждения терминов вообще, теперь же хочешь однозначности трактовки.
DG>>я говорил, что фиксировать термины без фиксирования задачи не имеет смысл. S>Если ты их не фиксировал, почему их употребляешь?
потому что это эффективный способ общения. Понятия используются без жесткой фиксации, каждый из собеседников их сам восстанавливает до непротиворечивого состояния из контекста на основе своих алгоритмов. Если в ходе беседы выясняется, что понятия восстанавливаются по разному (например, на основе того, что выводы у собеседников получаются разные), то сравниваются алгоритмы используемые для определения и восстановления понятий
Здравствуйте, DarkGray, Вы писали: DG>при этом используется, что в реальных программах необходима однозначность значимой части результата, и что одновременно две функции F не исполняются
Вторая часть предположения
а) слишком сильная, т.е. не основана ни на чём, кроме веры
б) недостаточно сильная, т.к. даже без "одновременного исполнения" двух функций F мы можем получить спецэффекты, которые вашей программой не предусмотрены.
Вот такого примера достаточно:
int HellSum(IEnumerable<int> source)
{
var s = 0;
foreach(var i in F(source))
{
s+= i;
_a = 0;
}
}
IEnumerable<int> F(IEnumerable<int> source)
{
foreach(var i in source)
{
_a = i ^ (i << (_a &&0x4)) ^ (i >> 16));
yield return i ^ _a;
}
}
private int _a = 42;
DG>декларация же может быть задана в виде: результат должен быть таким же, как результат вот такого-то вычисления, а выполнять можете как хотите (и для сложных алгоритмов нет другого способа задания результата)
Как интересно. То есть вы настаиваете, что разницы между декларативным и императивным описаниями нет. Тогда объясните это vdimas-у, а то он почему-то считает РА более императивной, чем РИ.
DG>при этом утверждение "делайте как хотите, главное чтобы результат был тем же самым" и так уже говорится, что для ФЯ, что для ООП и т.д. — что внутреннее поведение неважно, важно чтобы сохранялось внешнее поведение(внешний результат)
Вы движетесь в правильную сторону. Остаётся понять, что такое "внешнее поведение", и вы сможете отличить декларативную программу от императивной.
DG>что две спецификации результата, отличающиеся лишь спецификацией результата для некорректного поведения — для значимой части программ являются одной и той же спецификацией.
Отлично. Осталось определить, что такое "корректное поведение", что такое "некорректное поведение", и что такое "результат". А то вот вы взяли и "исправили" мою программу, написав свою. Да, "результат" работы вашей программы иногда получается таким же, как и у моей программы.
Но ведь тогда я могу в некоторой библиотеке заменить вычисление синуса на return 0; сказав, что во всех корректных программах аргумент всегда равен нулю, а те, кто передаёт не ноль — сами виноваты. Чем моя аргументация будет хуже вашей? Она столь же произвольна.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>>>как ты собираешься проверять условие без выполнения чего-либо? S>>Линейкой. Мерили ведь раньше без выполнения чего-либо.
DG>чтобы измерить линейкой уже необходим исполнитель в виде человека с инструкцией, что такое линейка, куда ее прикладывать, какой стороной, и на что смотреть.
Кому как
DG>>>никакого свыше нет. "порядок" даже не является аксиоматическим понятием. S>>Аксиоматическим — нет. Но когда клиент говорит что ему нужна упорядоченная последовательность, то возникает вопрос лишь "по какому признаку", а не о том, как трактовать "порядок".
DG>это как-то доказывает, что все люди трактуют понятие "упорядоченная последовательность" однозначным способом?
Это как раз доказывает что есть люди, которые считают что понятие "упорядоченная последовательность" неоднозначно. Хотя на самом деле оно однозначно.
DG>>>в виде алгоритма для абстрактного вычислителя S>>Требования к результату могут быть выражены без алгоритма абстрактного вычислителя. Например: по росту. Всё. Где здесь алгоритм? Где вычислитель?
DG>что "по росту"?
Это требование к результату.
S>>>> потом они (либо инструкции по получению результата) записываются в коде для определенного вычислителя согласно его правилам вычисления.
DG>>>потом исходный алгоритм для абстрактного вычислителя преобразуется в алгоритм для определенного вычислителя S>>Определенный вычислитель может не пользоваться алгоритмами явно.
DG>пример такого вычислителя
Например, если принять за вычислитель человека, то для проверки требования "по росту" ему достаточно "прикинуть на глазок", не объясняя алгоритмов и куда прикладывать линейку.
DG>>>я говорил, что фиксировать термины без фиксирования задачи не имеет смысл. S>>Если ты их не фиксировал, почему их употребляешь?
DG>потому что это эффективный способ общения. Понятия используются без жесткой фиксации, каждый из собеседников их сам восстанавливает до непротиворечивого состояния из контекста на основе своих алгоритмов. Если в ходе беседы выясняется, что понятия восстанавливаются по разному (например, на основе того, что выводы у собеседников получаются разные), то сравниваются алгоритмы используемые для определения и восстановления понятий
Я считаю что ты не можешь называть свое общение здесь эффективным. Вот пример из другого форума
зафиксировали что есть последовательность писем (и отдельно отмечу, что слово последовательность здесь лишь означает, что писем много, что можно считать, что они примерно одного и того же типа, и что их можно перебрать тем или иным способом, и не означает, что письма хранятся в виде последовательности)
Эффективным было бы сказать "есть множество писем", уповая на то, что собеседник знает что такое множество, а не объяснять что под последовательностью ты подразумеваешь множество, вопреки понятию "последовательность".
В итоге выходит что ты употребляешь термины без жесктой фиксации, а собеседники должны все время догадываться, в каком смысле ты их употребил, потому как неизбежно возникают противоречия (см. так же чистоту с побочными эффектами), которые и порождает массу флуда.
