Автор Тема: Выход из цикла или смерть Кощея  (Прочитано 92126 раз)

DddIzer

  • Гость
Re: Выход из цикла или смерть Кощея
« Ответ #195 : Январь 23, 2013, 07:43:46 am »
Это к слову о нужности или ненужности макросов, даже таких простых, как сишные. Не нужно ждать, когда разработчики языков добавят нужную вам конструкцию -- добавьте её сами!
Тык давайте Немерлееть -- Петр- в эту сторону смотреть не пробовали? - на шарп похоже.. :)
Алмазов терпеть не может макросы вообще и немерле в частности )))
тык макросы в Немерли это не макросы в Си... и потом, заметил я, что при удобном случае он приводит шарпейный код...  а  от туда до Немерли и рукой подать  :D

Peter Almazov

  • Sr. Member
  • ****
  • Сообщений: 482
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #196 : Январь 23, 2013, 10:49:42 am »
Алмазов терпеть не может макросы вообще и немерле в частности )))
Первое верно, а второго я никогда не говорил.
Ибо ни хрена в них не понял.

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #197 : Январь 31, 2013, 04:24:47 pm »
Функция без побочных эффектов (она же "чистая") - это функция, которая для одних и тех же аргументов всегда возвращает один и тот же результат и сама не вызывает функций с побочными эффектами.
...
Такая функция будет вносить (вообще говоря) побочные эффекты в выражения в которых она вызывается.
Добавлю. Чистая, но с побочными эффектами, функция, в общем случае сделает выражения в которых она вызывается также и нечистыми. Значения этих выражений уже не будут задаваться значениями их designator-операндов - это если включить вызовы функций в выражения (express), а не в составные имена (designator).
Потому что, результат побочного изменения (такой функцией) значений внешних переменных (входящих в то же выражение, что и ее вызов) уже не обязан подчиняться требованию чистоты - нечистая функция не будет "для одних и тех же аргументов" всегда устанавливать одно и то же значение внешних designator-операндов.


2. С чего бы это (точнее не всегда) - если речь идет о классическом (пошаговом, детерменированном) алгоритме в однозадачной системе то по возвращаемое функцией в ссылочном значении эквивалентно чистому присваиванию (а возможные переприсваивания внутри функции не влекут изменения в глобальном окружении) - можно конечно более точно привести необходимые и достаточные условия для этого.. но - см. п1.
2. Присваивание глобальной переменной и есть побочный эффект, это оператор, а не функция. Динамическая анонимная переменная, на которую ведет ссылка, это глобальное окружение, и если ее (анонимной переменной) значение меняется - это побочный эффект.
В отличие от самой ссылки-результата (она не является глобальным окружением), чей анонимный вспомогательный объект расположен в стеке выражения, и к значению которой можно получить доступ только в рамках содержащего ее выражения. Когда ссылке-результату, при возврате из вызова функции, присваивается ссылочное значение, ссылающееся на ту или иную глобальную динамическую переменную (не изменяя их), это не создает побочного эффекта.
Надеюсь, вы имеете ввиду то же самое.
Но чтобы еще функция при этом была чистой (в вашей терминологии), необходимо чтобы ее ссылочное значение-результат совпадало со ссылочным значением одной из компонент ее аргументов либо равнялось NIL, иначе (если оно создается, или берется из компонент неявно импортируемых именованных переменных или из компонент анонимных динамических переменных) ссылочный результат невозможно вывести из значений аргументов.
3. Я воспринял задачу так - как необходимость использовать функцию не содержащую побочный эффект - причем эффект вынужденный (следующий из паттерна решения основной задачи но не родственный природе самой функции).
3. Использовать функции с побочным эффектом или не использовать, это вопрос конкретного решения, в том числе характера типизации данных (со ссылками или без). Я не заметил, чтобы автор задачи требовал безпобочности функций.
4. Я имел ввиду другое.. реально программа в функциональном яп транслируется в си.. и далее... который вполне императивен.. - вы можете сказать когда создаются фактические динамические переменные , а когда нет?.. между тем согласно вашей же фразе (если я правильно ее понял) любое создание динамической переменной есть побочный эффект... отсюда вывод фяву - в общем случае языки с неконтролируемым побочным эффектом ...
4. Это неважно куда там все транслируется и что там глобально-динамическое внутри создается, все это ненаблюдаемо средствами самого ФЯП, средствами среды его исполнения. Только создание динамической переменной рассматриваемого языка (а не переменной в его низкоуровневой реализации) является побочным эффектом.

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #198 : Январь 31, 2013, 04:31:40 pm »
Автор выдвигает несколько метафизические требования к минимализму числа выполненных действий, пытаясь ввести новые формы структурных операторов. Забывая, что внутри структурных операторов тоже ведь спрятаны определенные действия (передача управления, установка скрытых флагов).
Даже "лишняя" проверка булевой переменной для него уже неприемлема, хотя это всего лишь вспомогательный флаг для структуризации алгоритма. Надуманного повода со сложностью извлечения объектов будет недостаточно для такого сильного требования.
Если он хочет совсем без лишних проверок и действий, то ему, в общем случае, нужны неструктурные блок-схемы. По крайней мере, ему нужен новый структурный оператор без вложенных субоператоров (операторных параметров, которые и дают лишние проверки и действия). То есть, если поместить все элементы нужной блок-схемы на один структурный уровень - вся "спагетти" переходов между этими элементами блок-схемы перейдет в один структурный оператор со сложной передачей управления внутри себя.

Также, не следует ли объединить извлечение из вещи с проверкой ее внутренности на пустоту?
Это будет такая вот функция извлечения с побочным эффектом:
ИзвлечениеВещь (IN вещь; OUT субвещь) непустой: BOOLEAN(*post: "субвещь" - неопределена, если "вещь" определена, но пуста*)
а также функции перехода к первому и следующему сундуку:
Первый (OUT сундук) есть: BOOLEAN(*post: "сундук" - неопределен, если нет ни одного сундука*)
Следующий (VAR сундук) есть: BOOLEAN(*post: "сундук" - неопределен, если исходное значение "сундук" определено, но следующего за ним нет*)

Алгоритм воплощается в виде такого структурного оператора почти с чисто логическими параметрами-выражениями, то есть почти без операторных параметров.
existDeath := FALSE; (* смерть Кощея пока не найдена *)

BEGINIF (* переход к WHILEIF, если условие истинно (первый сундук есть), и выход из оператора, если ложно *)
First(сhest) (* проверка, что первый сундук есть, и переход к нему *)
WHILEIF (* переход к следующему UNTIL, если условие истинно (сундук пустой), и к следующему ELSIF, если ложно *)
~UnpackChest(сhest, hare) (* проверка, что в сундуке есть заяц и его извлечение *)
UNTIL (* выход из оператора, если условие истинно (следующего сундука нет), и возврат к WHILEIF, если ложно *)
~Next(сhest) (* проверка, что следующий сундук есть, и переход к нему *)
ELSIF (* переход к следующему UNTIL, если условие истинно (заяц пустой), и к следующему ELSIF, если ложно *)
~UnpackHare(hare, duck) (* проверка, что в зайце есть утка, и ее извлечение *)
UNTIL
~Next(сhest)
ELSIF (* переход к следующему UNTIL, если условие истинно (утка пустая), и к следующему ELSIF, если ложно *)
~UnpackDuck(duck, egg) (* проверка, что в утке есть яйцо, и его извлечение *)
UNTIL
~Next(сhest)
ELSIF (* переход к следующему UNTIL, если условие истинно (яйцо пустое), и к следующему ELSIF, если ложно *)
~UnpackEgg(egg, needle) (* проверка, что в яйце есть игла, и ее извлечение *)
UNTIL
~Next(сhest)
ELSIF (* переход к следующему UNTIL, если условие истинно (игла пустая), и к ELSE, если ложно *)
~UnpackNeedle(needle, death) (* проверка, в игле есть смерть Кощея, и ее извлечение *)
UNTIL (* выход из оператора, если условие истинно (следующего сундука нет), и возврат к WHILEIF, если ложно *)
~Next(сhest)
ELSE (* выполнение субоператоров и выход из оператора *)
existDeath := TRUE (* смерть Кощея найдена *)
END;

Очевидно, что минимальное количество действий и проверок зависит от того, как нам доступны данные: с помощью каких структур (со ссылками, без ссылок), процедур и функций. Автор не конкретизировал используемый инструментарий.

Сегмент
BEGINIF (* переход к WHILEIF, если условие истинно (первый сундук есть), и выход из оператора, если ложно *)
First(сhest) (* проверка, что первый сундук есть, и переход к нему *)
здесь можно заменить на сегменты внешнего IF-оператора
IF (* переход к THEN, если условие истинно (первый сундук есть), и выход из оператора, если ложно *)
First(сhest) (* проверка, что первый сундук есть, и переход к нему *)
THEN (* выполнение субоператоров и выход из оператора *)
а после вложенного в него оператора цикла добавить закрывающее END для IF-оператора.
Тогда оператор цикла немного упростится.

Можно после каждого UNTIL-сегмента этого оператора цикла добавить THEN-сегмент
THEN (* выполнение субоператоров и выход из оператора *)
UnassignHare(hare); (* установка неопределенного значения переменной hare *)
UnassignDuck(duck); (* установка неопределенного значения переменной duck *)
UnassignEgg(egg); (* установка неопределенного значения переменной egg *)
UnassignNeedle(needle) (* установка неопределенного значения переменной needle *)
к которому идет переход от этого UNTIL-сегмента, если его условие истинно.
Тогда сделаются неопределенными значения переменных hare, duck, egg и needle, если смерть Кощея не была найдена. Но тогда же будут лишние затирания значений переменных "Вещь", если вещи какого-либо типа из перечисленных ни разу не находились.

Можно перед каждым ELSIF-сегментом этого оператора цикла добавить ";"-сегмент
; (* выполнение субоператоров и переход к следующему ELSIF *)
existВещь := TRUE (* вещь данного типа была обнаружена *)
к которому идет переход от предыдущего WHILEIF- или ELSIF-сегмента, если его условие ложно.
И перед оператором цикла дописать
existHare := FALSE; (* заяц пока не был обнаружен *)
existDuck := FALSE; (* утка пока не была обнаружена *)
existEgg := FALSE; (* яйцо пока не было обнаружено *)
existNeedle := FALSE; (* игла пока не была обнаружена *)
а THEN-сегменты привести к виду
THEN
IF existHare THEN UnassignHare(hare) END;
IF existDuck THEN UnassignDuck(duck) END;
IF existEgg THEN UnassignEgg(egg) END;
IF existNeedle THEN UnassignNeedle(needle) END
Тогда лишних затираний значений вызовами процедур UnassignВещь не будет, но появятся дополнительные переменные existВещь. И будут повторные (лишние) присваивания переменным existВещь в ";"-сегментах, если вещи какого-либо типа из перечисленных находились несколько раз.

Наконец, можно ";"-сегменты заменить такими же UNE-сегментами, но выполняющими свое тело не более одного раза за каждый вызов цикла, а в повторные разы сразу передающими управление следующему сегменту, как будто UNE-сегмент удален.
UNE
existВещь := TRUE
Тогда повторных присваиваний также не будет, но будут лишние передачи управления либо скрытая динамическая кодогенерация.

К сожалению, без использования динамической кодогенерации либо лишних передач управления, либо лишних проверок, присвоений или вызовов процедур невозможно сделать неопределенными значения переменных hare, duck, egg, needle в случае если смерть Кощея не была найдена.

Общая структура такого оператора цикла:
  BEGINIF (* expressBoolean истинно: переход к переход к WHILEIF,
   expressBoolean ложно:   выход из оператора *)
expressBoolean
  WHILEIF (* expressBoolean истинно: переход к первому следующему DO | THEN | UNTIL,
   expressBoolean ложно:   переход к первому следующему ";" | UNE | ELSIF | ELSE | выход из оператора *)
expressBoolean
( DO (* выполнение statementExpress и возврат к WHILEIF *)
statementExpress
| THEN (* выполнение statementExpress и выход из оператора *)
statementExpress
| UNTIL (* expressBoolean истинно: переход к первому следующему THEN | выход из оператора,
   expressBoolean ложно:   возврат к WHILEIF *)
expressBoolean
 [THEN (* выполнение statementExpress и выход из оператора *)
statementExpress])
{{";" (* выполнение statement и переход к первому следующему ";" | UNE | ELSIF *)
statement
| UNE (* выполнение (если ни разу за вызов цикла не выполнялся) statement и переход к первому следующему ";" | UNE | ELSIF *)
statement}
  ELSIF (* expressBoolean истинно: переход к первому следующему DO | THEN | UNTIL,
   expressBoolean ложно:   переход к первому следующему ";" | UNE | ELSIF | ELSE | выход из оператора *)
expressBoolean
( DO (* выполнение statementExpress и возврат к WHILEIF *)
statementExpress
| THEN (* выполнение statementExpress и выход из оператора *)
statementExpress
| UNTIL (* expressBoolean истинно: переход к первому следующему THEN | выход из оператора,
   expressBoolean ложно:   возврат к WHILEIF *)
expressBoolean
 [THEN (* выполнение statementExpress и выход из оператора *)
statementExpress])}
[ ELSE (* выполнение statementExpress и выход из оператора *)
statementExpress]
END
Здесь присутствуют длинные переходы между сегментами оператора, а это не самый приемлемый вариант цикла. Классический случай, когда есть только переходы: к соседнему следующему сегменту, к сегменту возврата (единственному на оператор), и выход из оператора. Не рассматриваем случай структурного выхода по метке или по метке ошибки. Притом, у каждого типа сегмента может быть только один или два вида перехода, фиксированных для него. Два вида перехода у сегмента возможны, когда у оператора имеются скрытые флаги-переменные.
Также, у оператора может быть множество параметров-выражений, задающих своими значениями значения скрытых параметров-переменных и параметров-констант оператора.


Параметры-составные имена у операторов (WITH, :=), и у вызовов процедур тоже, плохи тем, что при той же текстовой записи обозначают как адреса объектов, так и их значения.
Параметры-имена у некоторых операторов (FOR) реализованы неправильно из-за модификации области видимости объектов и пространства имен.
Параметры-типы у операторов (WITH) идеологически неприемлемы, ибо типовым значениям вообще нечего делать в операторной области (тела модулей и процедур), то есть в том числе и в выражениях и в составных именах, типы объектов при вызове (загрузке) процедур и модулей должны быть фиксированы в пределах каждой области видимости.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #199 : Январь 31, 2013, 05:22:35 pm »
Чистая, но с побочными эффектами, функция

Это оксюморон.
Чистая функция не должна иметь побочных эффектов, иначе это уже не функция, а действие (процедура).
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #200 : Февраль 01, 2013, 07:29:24 am »
Чистая, но с побочными эффектами, функция

Это оксюморон.
Чистая функция не должна иметь побочных эффектов, иначе это уже не функция, а действие (процедура).
Функция, чтобы быть функцией, должна выдавать результат в выражение и вызываться в нем (как подпрограмма) через постфиксную операцию (круглые скобки и запятые) с несколькими параметрами-выражениями этой операции, дающих функциональное значение и значения ее фактических параметров:
expressFunction
"("
[express
{","
express}]
")"
Если результат в выражение выдает непосредственно сам оператор, это уже операторное выражение, а не функция. Хотя, при большом желании, это можно считать подобием INLINE-функции, только с подстановкой ее кода прямо в тексте, а не при компиляции или загрузке как у обычной INLINE.

1. Функция с побочным эффектом общему определению функции удовлетворяет. Во многих ЯП есть функции, но в очень немногих из них все функции не имеют побочных эффектов.

2. Побочный эффект это изменение вызовом функции ее внешнего окружения, а нечистота функции это влияние внешнего окружения не через значения ее фактических параметров на ее результат. Это независимые свойства!
Может быть не только чистая функция без побочных эффектов и нечистая функция с побочными эффектами, но и нечистая функция без побочных эффектов, и чистая функция с побочными эффектами!

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #201 : Февраль 01, 2013, 07:38:36 am »
1. Функция с побочным эффектом общему определению функции удовлетворяет. Во многих ЯП есть функции, но в очень немногих из них все функции не имеют побочных эффектов.

То, что в этих языках процедуры обзывают функциями, ещё не делает их функциями.

2. Побочный эффект это изменение вызовом функции ее внешнего окружения, а нечистота функции это влияние внешнего окружения не через значения ее фактических параметров на ее результат. Это независимые свойства!
Может быть не только чистая функция без побочных эффектов и нечистая функция с побочными эффектами, но и нечистая функция без побочных эффектов, и чистая функция с побочными эффектами!

Чистую функцию без побочных эффектов можно закешировать (мемоизировать, табулировать).
Если значение функции зависит не только от её параметров или функция влияет на своё окружение, производя какие-то действия, их нельзя кешировать, иначе нарушится логика работы программы. Поэтому такие функции (грязные -- зависящие не только от параметров и влияющие на окружение) следует называть процедурами, даже если они возвращают какие-то значения. А ещё лучше -- действиями (actions).
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #202 : Февраль 01, 2013, 09:13:17 am »
1. Функция с побочным эффектом общему определению функции удовлетворяет. Во многих ЯП есть функции, но в очень немногих из них все функции не имеют побочных эффектов.
То, что в этих языках процедуры обзывают функциями, ещё не делает их функциями.
Однако же вы тоже называете их функциями, пользуетесь терминологией Врага! А-а-а!!!
... или функция влияет на своё окружение... Поэтому такие функции (грязные -- зависящие не только от параметров и влияющие на окружение)...
а нужно было говорить:
Цитировать
... или подпрограмма влияет на своё окружение... Поэтому такие подпрограммы (грязные -- зависящие не только от параметров и влияющие на окружение)...

и обзываете просто функцию чистой функцией
... Чистую функцию без побочных эффектов...
Функция не может не быть чистой и без побочных эффектов! Только процедуры могут.
а нужно было говорить:
Цитировать
... Чистую подпрограмму выдающую значение и без побочных эффектов...

С волками жить...


Поэтому такие функции (грязные -- зависящие не только от параметров и влияющие на окружение) следует называть процедурами, даже если они возвращают какие-то значения. А ещё лучше -- действиями (actions).
Такие функции лучше просто запретить. Не должно быть процедур, хоть как их называй, которые выдают значения и имеют побочные эффекты.
А вот чистота функций и выражений излишня. Например, точность вычислений, или диапазон значений, или результат при ошибке (в исходной настройке функции) не обязательно задавать через параметр. Функции могут использовать множество неявно импортируемых констант и даже переменых.

Также неплохо при полном запрете побочных эффектов в выражениях, сделать у функций лениво-вычисляемые параметры, также как у всех операций.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #203 : Февраль 01, 2013, 09:15:50 am »
http://ru.wikipedia.org/wiki/Чистота_функции

Цитировать
В функциональных языках программирования, чистая функция, это функция, которая:
является детерминированной;
не обладает побочными эффектами.

Наличие только одного из свойств недостаточно, для того чтобы функция была чистой.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #204 : Февраль 01, 2013, 09:17:10 am »
Также неплохо при полном запрете побочных эффектов в выражениях, сделать у функций лениво-вычисляемые параметры, также как у всех операций.

Добро пожаловать в Хаскелл!
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #205 : Февраль 01, 2013, 09:53:30 am »
http://ru.wikipedia.org/wiki/Чистота_функции

Цитировать
В функциональных языках программирования, чистая функция, это функция, которая:
является детерминированной;
не обладает побочными эффектами.

Наличие только одного из свойств недостаточно, для того чтобы функция была чистой.
Значит, DddIzer пользовался неправильным определением чистоты, или привел неполное определение. То, что он назвал чистотой (и я вслед за ним) есть в действительности детерминированность.

В функциональных ЯП понятное дело все функции чистые. Там небывает скрытых параметров (кроме предопределенных констант), и глобальных переменных (и даже просто переменных) нет совсем. Операторов там тоже нет.


Также неплохо при полном запрете побочных эффектов в выражениях, сделать у функций лениво-вычисляемые параметры, также как у всех операций.

Добро пожаловать в Хаскелл!
Это следует сделать в императивных ЯП, а не эмигрировать "в функционашку из сраной имперашки".

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #206 : Февраль 01, 2013, 10:16:51 am »
Также неплохо при полном запрете побочных эффектов в выражениях, сделать у функций лениво-вычисляемые параметры, также как у всех операций.

Добро пожаловать в Хаскелл!

Это следует сделать в императивных ЯП, а не эмигрировать "в функционашку из сраной имперашки".

В Хаскелле есть императивное подмножество. Один из разработчиков Хаскелла -- Саймон Пейтон Джонс -- заявил как-то, что Хаскелл является прекраснейшим из императивных языков. Пошутил, наверное...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #207 : Февраль 01, 2013, 10:23:54 am »
В Хаскелле есть императивное подмножество. Один из разработчиков Хаскелла -- Саймон Пейтон Джонс -- заявил как-то, что Хаскелл является прекраснейшим из императивных языков. Пошутил, наверное...
Хм, а я думал он функциональный. Обманули.
Если там есть хоть какое императивное подмножество, он уже не ФЯП.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Выход из цикла или смерть Кощея
« Ответ #208 : Февраль 01, 2013, 10:35:14 am »
В Хаскелле есть императивное подмножество. Один из разработчиков Хаскелла -- Саймон Пейтон Джонс -- заявил как-то, что Хаскелл является прекраснейшим из императивных языков. Пошутил, наверное...

Хм, а я думал он функциональный. Обманули.
Если там есть хоть какое императивное подмножество, он уже не ФЯП.

Императивное подмножество в нём чётко отделено от чистого функционального -- на уровне системы типов.
Любой реальный язык программирования должен как-то взаимодействовать с внешним миром -- ввод/вывод производить. Любые действия ввода/вывода, изменение глобальных переменных (а ввод/вывод можно рассматривать как изменение глобального состояния программы), недетерменированность вроде случайных чисел -- всё это считается действиями ввода/вывода и обозначается как действия ввода/вывода (IO actions).
Что попадёт в эти IO actions -- обратно уже не выберется.
Императивные процедуры могут вызывать чистые функции, но не наоборот -- система типов не позволит.

Так что можно считать, что фактически есть два языка, называемых общим словом "Хаскелл" -- императивный и функциональный.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

DddIzer

  • Гость
Re: Выход из цикла или смерть Кощея
« Ответ #209 : Февраль 02, 2013, 07:51:49 am »

Значит, DddIzer пользовался неправильным определением чистоты, или привел неполное определение. То, что он назвал чистотой (и я вслед за ним) есть в действительности детерминированность.

:Скорее "нестандартным" -  ибо стандартное ведет в данном случае к бессмысленному (в контексте данной задачи) словоблудию - которое вы продемонстрировали.. (да и вранье что вы следовали за мной - свое отношение к топику как задачи на тему -нах. сесть и конфетку съесть - я высказал четко и давно,а также отказался от дискуссии на эту тему с вами...)