Здравствуйте, Курилка, Вы писали:

К>a и b — логические предикаты (или ещё лучше прямые на плоскости), объясни математический смысл выражения a-b

Если не трындеть, то достаточно сказать, что при преобразовании многих алгоритмов в программы программистам в компании с математиками приходится заниматься тем, чтобы при вызове sqrt не возникала ошибка DOMAIN_ERROR и чтобы разность двух близких значений помещалась в double без каких-либо обращений в ноль.

Здравствуйте, Sinclair, Вы писали:

E>>А на счет изменности функций:
E>>

E>>int sum( int[] a ) {
E>>  int r = 0;
E>>  for( int i = 0; i != a.length; ++i )
E>>    r += a[ i ];
E>>  return r;
E>>}
E>>

E>>Чем эта функция изменна?
S>Не понял вопрос.

По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?

S>Вам непонятно, что r является изменчивым состоянием?

Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.

S>что i является изменчивым состоянием, и даже банальное доказательство того факта, что ни одно из обращений не выходит за пределы границ массива является нетривиальным?

Ok. Имеем чистую функциональную функцию:

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, index + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}

Или ее аналог в OCaml (навскидку):

let rec sum a =
  let rec sum_impl a index size acc =
    if index = size then acc
    else sum_impl a (index+1) size (acc+a[index])
  in
    sum_impl a 0 a.length 0

Проверка выхода за границы массива стала тривиальнее?

S>Еще раз: для чистой функции никаких причин жрать стек такими объемами нету вообще. Если компилятор неспособен свести ее потребление памяти к двум регистрам — это проблемы компилятора, а не ФП.

Хорошо, что позволит компилятору свести потребление памяти к минимуму вот в такой реализации:

let rec sum a =
  let rec sum_impl a index size =
    if index = (size-1) then a[index]
    else a[index] + (sum_impl a (index+1) size)
  in
    sum_impl a 0 a.length

?

E>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность.
E>>В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
S>Вот этого не понял.

Разность двух близких действительных чисел может не иметь представления в виде числа на компьютере.

E>>Какие побочные эффекты у приведенной выше императивной функции sum?
S>У приведенной выше — никаких.

Здорово -- побочных эффектов нет, зато состояние есть.

S>Поэтому хороший компилятор избавляется от излишней императивности в меру своих возможностей.

Уж компилятор просто вынужден всю имеющуюся в программе функциональщину сводить к самой дебильной императивности в виде инструкций процессора. Это если мы еще не начали говорить о сферических конях в вакууме.

E>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность. В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
К>a и b — логические предикаты (или ещё лучше прямые на плоскости), объясни математический смысл выражения a-b

В геометрической алгебре есть смысл этого выражения, по-моему. Это пересечение дополнений (дуальных элементов, по-моему) a и b.

Здравствуйте, eao197, Вы писали:
E>По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?
Функция aux ничего не говорит о каких-либо изменениях. Она задает отображение входных параметров на выходные, безо всяких промежуточных "шагов".

E>Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.
Ничего подобного. Аргументы в FP-подходе — это всего лишь обозначения. У них никакого "состояния нет"; они не изменяются во времени. В ФП все r и i — различные. Да, в некоторых частных случаях императивные программы ведут себя так же. Но это никак не отменяет всех остальных императивных программ.


E>Ok. Имеем чистую функциональную функцию:
E>

E>int sum( int[] a ) {
E>  int sum_impl( int[] a, int index, int result ) {
E>    if( index != a.length )
E>      return sum_impl( a, index + 1, result + a[ index ] );
E>    else
E>      return result;
E>  }
E>  return sum_impl( a, 0, 0 );
E>}
E>

E>Или ее аналог в OCaml (навскидку):
E>

E>let rec sum a =
E>  let rec sum_impl a index size acc =
E>    if index = size then acc
E>    else sum_impl a (index+1) size (acc+a[index])
E>  in
E>    sum_impl a 0 a.length 0
E>

E>Проверка выхода за границы массива стала тривиальнее?
Конечно. Если компилятор вообще заботится о таких вещах, как корректность программы, то он должен сразу дать по рукам за такую программу. И заставить ее переписать так, чтобы требование на неотрицательность индекса было явно выражено в типе аргумента — или соответствующий guard появился в теле sum_impl. И заменить != a.length на < a.length
S>>Еще раз: для чистой функции никаких причин жрать стек такими объемами нету вообще. Если компилятор неспособен свести ее потребление памяти к двум регистрам — это проблемы компилятора, а не ФП.

E>Хорошо, что позволит компилятору свести потребление памяти к минимуму вот в такой реализации:
E>

E>let rec sum a =
E>  let rec sum_impl a index size =
E>    if index = (size-1) then a[index]
E>    else a[index] + (sum_impl a (index+1) size)
E>  in
E>    sum_impl a 0 a.length
E>

E>?

E>>>Еще одно серьезное различие между программированием и математикой в том, что числа в программировании имеют размерность.
E>>>В математике выражение (a-b) имеет смысл всегда. А в программировании -- нет.
S>>Вот этого не понял.

E>Разность двух близких действительных чисел может не иметь представления в виде числа на компьютере.

E>>>Какие побочные эффекты у приведенной выше императивной функции sum?
S>>У приведенной выше — никаких.

E>Здорово -- побочных эффектов нет, зато состояние есть.

S>>Поэтому хороший компилятор избавляется от излишней императивности в меру своих возможностей.

E>Уж компилятор просто вынужден всю имеющуюся в программе функциональщину сводить к самой дебильной императивности в виде инструкций процессора. Это если мы еще не начали говорить о сферических конях в вакууме.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, LaPerouse, Вы писали:

LP>>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.

FR>Кстати стека не будет, там хвостовая рекурсия.

Я что-нибудь говорил про вид рекурсии? Рекурсия может быть любой, процесс может является итеративным или не являться им. Процесс, описываемый этой функцией

int sum( int[] a ) {
  int sum_impl( int[] a, int index, int result ) {
    if( index != a.length )
      return sum_impl( a, i + 1, result + a[ index ] );
    else
      return result;
  }
  return sum_impl( a, 0, 0 );
}

итеративный.

Давай его перепишем, чтобы он стал рекурсивным:

int sum( int[] a ) {
    int sum_impl( int[] a, int index ) {
            if( index != a.length )
                return a[ index ] + sum_impl( a, i + 1);
            else
                return a[ index ];
    }
    return sum_impl( a, 0);
}

Итеративный процесс отличается от рекурсивного тем, что в нем присутствует переменная, которая характеризует текущее состояние вычислительного процесса. В данном случае это переменная result. В рекурсивном процессе информация заложена в стеке.

По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, LaPerouse, Вы писали:

LP>>Оттого, что r уехал в стек процесс не изменится — он останется итерационным. Просто состояние будет на стеке. А процесс остался итерационным.

FR>Вообще то обе функции чистые, а вторая вообще полная фукциональщина даже локального сосотояния не использует, так что императивщины тут уже нет.

Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:
E>>По поводу функции aux, написанной FR, было сказана, что она "неизменна". Следовательно, раз эта функция не в ФП стиле, значит она "изменна". Вот мне и интересно -- как именно. Что такого она может изменить? Собственно тело?
S>Функция aux ничего не говорит о каких-либо изменениях. Она задает отображение входных параметров на выходные, безо всяких промежуточных "шагов".

E>>Нет. Если называть r и i состояние, то это то же самое, что и аргументы в рекурсивных вызовах в ФП подходе.
S>Ничего подобного. Аргументы в FP-подходе — это всего лишь обозначения. У них никакого "состояния нет"; они не изменяются во времени. В ФП все r и i — различные. Да, в некоторых частных случаях императивные программы ведут себя так же. Но это никак не отменяет всех остальных императивных программ.


E>>Ok. Имеем чистую функциональную функцию:
E>>

E>>int sum( int[] a ) {
E>>  int sum_impl( int[] a, int index, int result ) {
E>>    if( index != a.length )
E>>      return sum_impl( a, index + 1, result + a[ index ] );
E>>    else
E>>      return result;
E>>  }
E>>  return sum_impl( a, 0, 0 );
E>>}
E>>

E>>Или ее аналог в OCaml (навскидку):
E>>

E>>let rec sum a =
E>>  let rec sum_impl a index size acc =
E>>    if index = size then acc
E>>    else sum_impl a (index+1) size (acc+a[index])
E>>  in
E>>    sum_impl a 0 a.length 0
E>>

E>>Проверка выхода за границы массива стала тривиальнее?
S>Конечно. Если компилятор вообще заботится о таких вещах, как корректность программы, то он должен сразу дать по рукам за такую программу. И заставить ее переписать так, чтобы требование на неотрицательность индекса было явно выражено в типе аргумента — или соответствующий guard появился в теле sum_impl. И заменить != a.length на < a.length
S>>>Еще раз: для чистой функции никаких причин жрать стек такими объемами нету вообще. Если компилятор неспособен свести ее потребление памяти к двум регистрам — это проблемы компилятора, а не ФП.

Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет. Например, во второй функции eao никакого ФП, на мой взгляд, и нет, поскольку единственное, чем отличается эта функция от первой — это закидывание изменяемого состояния в стек. Примерно 50 процентов чистых функций, которые с гордостью демонстрируют функциональщики — это беззастеничивая, едва прикрытая императивщина, как в данном случае.
Можно, конечно, сказать, что ФП — это когда изменение состояния происходит на стеке, а не с помощью деструктивного присваивания. Но тогда давайте честно говорить, что всякий итеративный процесс выглядит одинаково и в императивной реализации при помощи дестр. присваивания, и в случае реализации через рекурсию.

Здравствуйте, thesz, Вы писали:

T>>>ФП Тьюринг-полно. Поэтому границ у него ровно столько же, сколько и у безгранично применявшегося до 1983 года императивного программирования.
LP>>Ты это говоришь, прекрасно зная, что полнота по Тьюрингу тут не при чем. Мол, милое дело развести императивного лошка подменой понятий. Полнота по Тьюрингу в данном случае ровно ничего не значит, поскольку она касается только вычислительного процесса. А программы, знаешь ли, помимо вычислений занимаются многими другими интересными вещами. Например, окошки выводят с кнопочками, пишут на диск (кто бы мог подумать!) и делают еще много чего, что не относится к вычислениям.

T>Вообще-то, это всё вычисления.

С чего это?

T>>>Меня смущает состояние. Императивщина.
LP>>Почему? Пусть твои модули, по крайней мере большинство будут функциональными, а их склейка — императивной, что в этом такого?
LP>>То есть будет висеть такое состояние:
LP>>State a;
LP>>И вместо того, чтобы каждая функция изменяла этот a, сделать изменение этого состояния через функции
LP>>State cleanFunction(State)
LP>>и потом собирать изменения в ограниченном числе императивных функции, тем более хаскель позволяет отделять такие функции по типу.
LP>>В результате мы получим почти true-функциональный дизайн внутри модулей и имеративную склейку между модулями. Что плохого в этом?

T>Таким образом мы не сможем спроектировать дизайн на потоках. Ни на бесконечных списках, ни на потоковых процессорах.

T>Наличие состояния затрудняет масштабирование решения. В отличии от отсутствия состояния.

Так я же не предлагаю его городить на каждом шаге. Вообще, и при ООП проектировании от лишнего состояния стараются избавиться, так как понятно, что состояние есть узкое место, затрудняющее масштабирование. Если модуль может быть реализован без состояния, он должен быть реализован без состояния. А в тех случаях, когда это невозможно, тогда и можно применять подход, который я привел.

LP>Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет. Например, во второй функции eao никакого ФП, на мой взгляд, и нет, поскольку единственное, чем отличается эта функция от первой — это закидывание изменяемого состояния в стек. Примерно 50 процентов чистых функций, которые с гордостью демонстрируют функциональщики — это беззастеничивая, едва прикрытая императивщина, как в данном случае.

Не, все же, думаю, это слишком категоричное утверждение. ФП — это когда отсутствует деструктивное присваивание и вообще изменение состояния непосредственно. Когда оно присутствует на стеке, как в случае с result, думаю, можно называть ФП. Но при этом нужно помнить, что никакой разницы в вычислительном процессе, который описывается циклом и хвостовой рекурсией, нет.

Здравствуйте, LaPerouse, Вы писали:

LP>Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.

Мне кажется не стоит путать итеративное и императивное.

Здравствуйте, LaPerouse, Вы писали:

LP>Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет. Например, во второй функции eao никакого ФП, на мой взгляд, и нет, поскольку единственное, чем отличается эта функция от первой — это закидывание изменяемого состояния в стек. Примерно 50 процентов чистых функций, которые с гордостью демонстрируют функциональщики — это беззастеничивая, едва прикрытая императивщина, как в данном случае.

ФП вполне четко определенная вещь. Есть чистота есть ФП, нет чистоты нет ФП. Все обсалютно прозрачно и вполне уловимо.

LP>Можно, конечно, сказать, что ФП — это когда изменение состояния происходит на стеке, а не с помощью деструктивного присваивания. Но тогда давайте честно говорить, что всякий итеративный процесс выглядит одинаково и в императивной реализации при помощи дестр. присваивания, и в случае реализации через рекурсию.

От того что итеративный процесс можно реализовать как функционально так и императивно не делает функциональную реализацию императивной.

Здравствуйте, FR, Вы писали:

LP>>Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.

FR>Мне кажется не стоит путать итеративное и императивное.

Как их можно путать? Это понятия разных категорий.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, LaPerouse, Вы писали:

LP>>Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.

FR>Мне кажется не стоит путать итеративное и императивное.

Я даже не знаю. Интуитивно мне кажется, что итеративное суть императивное, ибо разница только в способе записи. Но с другой стороны, отсутствует явное деструктивное присваивание, первый признак императивщины.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, FR, Вы писали:

LP>>>Ничего подобного. Обе функции фистые, но реализованы в доску императивным способом. Первая не стесняясь пользуется деструктивным присваиванием, вторая — маскирует его через стек.

FR>>Мне кажется не стоит путать итеративное и императивное.

C>Как их можно путать? Это понятия разных категорий.

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

Здравствуйте, LaPerouse, Вы писали:

LP>Я даже не знаю. Интуитивно мне кажется, что итеративное суть императивное, ибо разница только в способе записи. Но с другой стороны, отсутствует явное деструктивное присваивание, первый признак императивщины.

По моему чистая психология, как например то, что некторые ООП программисты убеждены что инкапсуляцию и полиморфизм придумали в и только для ООП и без нее они не сущесттвуют

Здравствуйте, LaPerouse, Вы писали:

LP>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.

Если они написаны на императивном языке — то да. А если на функциональном — то нет ни рекурсии, ни вызовов функций, ни стека. Есть только рекурентно записаное соотношение. И вычисление этого соотношения компилятор может реализовать как угодно. Естественно у этого соотношения нет ни состояния, ни побочных эффектов. Поэтому говорить, что ФП — это ИП с изменением состояния на стеке — неверно.

Здравствуйте, LaPerouse, Вы писали:

LP>Я выскажу свое мнение — на мой взгляд, ФП — эта такая неуловимая хрень, и далеко не сразу можно понять, где эта хрень есть, а где — нет.
Ну, во-первых, деструктивным присваивание становится только тогда, когда разрушает некоторое предыдущее значение.
Например, тут оно есть:

x = 10;
x = x+2;

А тут — уже нету:

x = 10;
y = x+2;

Во-вторых, ФП таки есть. Если пойти в теорию, то есть формализм частично вычислимых функций, и есть формализм машины Тьюринга.
Они вычислительно эквивалентны, но используют как бы разную нотацию для записи того и другого.
Обе модели являются чистой абстракцией, и для "выполнения" на реальной аппаратуре непригодны.

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

А вот эта "неуловимость" ФП связана как раз с ФП/ИП дуализмом: если избегать деструктивных присваиваний в процедурной программе, то она будет совпадать с некоторой функциональной программой с точностью до синтаксиса. А если ввести компонент "состояние" в результаты, над которыми оперируют функции в ФП программе, получим императивный алгоритм.

Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, LaPerouse, Вы писали:

LP>>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.

КБ>Если они написаны на императивном языке — то да. А если на функциональном — то нет ни рекурсии, ни вызовов функций, ни стека. Есть только рекурентно записаное соотношение. И вычисление этого соотношения компилятор может реализовать как угодно. Естественно у этого соотношения нет ни состояния, ни побочных эффектов. Поэтому говорить, что ФП — это ИП с изменением состояния на стеке — неверно.

Это просто фантастика какая-то. "Компилятор может реализовать как угодно" — возможно, через тридцать лет и будет такое, но пока компилятор делает именно то, что указывает программист. Он может сделать оптимизации по типу сворачивания хвостовой рекурсии, но изменить тип вычислительного процесса он не может. Хотя и говорят что-то там про CPS, но имхо это хардкор, который работает в 1 проценте из всех случаев и вещь довольно ненадежная, чтобы на нее полагаться.

Здравствуйте, LaPerouse, Вы писали:

LP>Здравствуйте, Константин Б., Вы писали:

КБ>>Здравствуйте, LaPerouse, Вы писали:

LP>>>По сути, два примера, которые привел eao ничем не отличаются друг от друга. Просто один реализован через деструктивное изменение переменной, второй — через передачу этой переменной в стеке. Обе функции описывают один и тот же итерационный процесс.

КБ>>Если они написаны на императивном языке — то да. А если на функциональном — то нет ни рекурсии, ни вызовов функций, ни стека. Есть только рекурентно записаное соотношение. И вычисление этого соотношения компилятор может реализовать как угодно. Естественно у этого соотношения нет ни состояния, ни побочных эффектов. Поэтому говорить, что ФП — это ИП с изменением состояния на стеке — неверно.

LP>Это просто фантастика какая-то. "Компилятор может реализовать как угодно" — возможно, через тридцать лет и будет такое, но пока компилятор делает именно то, что указывает программист. Он может сделать оптимизации по типу сворачивания хвостовой рекурсии, но изменить тип вычислительного процесса он не может.

Вы просто не понимаете что именно указывает программист когда он пишет на окамле let rec sum = ...
Эта запись не содержит рекурсивного вызова и не содержит указаний "положить аргументы на стек". Она только задает рекурентное соотношение.

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, eao197, Вы писали:

FR>По штанге хоть и жуткий оффтоп, это такая штука и калечит и лечит

Все хорошо в меру. Если физические кондиции позволяют, можно и под 100 кг штангой полежать. Но если скажем вес у тебя 50 килограмм, то какого хрена пытаться это делать? А ведь некоторые пытаются. "Каждый сверчок знай свой шесток". Один знакомый грыжу себе так заработал.