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

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

I>Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.
I>При чем тоже самое и в россии и в любой из стран бывшего ссср.
Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

S>>почва благодатная для домыслов-то. Большинство выпускников того ВУЗ-а о котором я рассказал тоже считают свой ВУЗ на голову выше прочих И даже считают себя ровней выпускникам головного МИФИ.

I>А у меня все просто — вуз где я учился ведущий в своем профиле. Как ты понимаешь, это много чего меняет.
Конечно ничего не меняет. ВУЗ о котором я пишу (кстати, вот здесь) — тоже ведущий в своем роде, в подготовке кадров для ядерного центра. Не хухры-мухры
Ведь те, что отучились на большой земле, не рвутся работать в этот центр. Бронь от армии больше не дают, а больше сюда ехать незачем.

I>Я и вижу.
и я вижу

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

I>>Ты внятно ответь на вопрос — где я предлагаю использовать С++ для обучения ? Есть простой факт — С++ крайне востребован в определенных областях, котрые крайне актуальны.
S>Это не делает его идеальным языком для обучения программированию. И даже идеальным языком для программирования вообще.

Для обучения программированию конечно же это плохой язык. Зато востребованность С++ означает, что студенты должны как минимум освоить этот С++, а начинать программуху конечно же лучше с другого языка.


I>>Представляю. SQL обычно используется чисто для выборки даннх и предварительной обработки. Основной процессинг всегда на сервере. Например потому, что для процессинга нужны данные из разных источников или же нужны все данные и сразу.
S>Простите, но настоящего SQL вы никогда не видели. "Основной процессинг". "Чисто для выборки данных". Не смешите меня, пожалуйста.
S>Даже если не пользоваться group by с having и подзапросами, а только джойнами, where и order by, то вы употеете делать аналогичную "чисто выборку данных" на императивном языке.

Это мизерная часть всех сценариев.

I>>В чем то ты прав, когда винда зависает от того, что лоток привода закрывается, то часто это означает, что драйвер писал программист который считал что драйверу скорость не нужна.
S>Вообще-то нет. Как правило, это означает, что драйвер писал программист, считающий скорость важнее корректности.
S>Чтобы понять, что вы пишете чушь, нужно представлять скорости современного железа. За время "закрытия лотка" процессор успевает намолотить столько, что заметных задержек в UI не даст даже JavaScript, интерпретируемый интерпретатором, написанным на SQL.
S>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать мало-
мальски интересных инвариантов.

Ну ладно, с лотком ты прав


I>>Вот оконному манагеру скорость точно не нужна, ибо он не занимается низкоуровневыми вещами, а они, в свою очередь, написаны на мега-оптимизированом инструменте.
S>Скорость и низкоуровневость связаны между собой вовсе не так, как вы полагаете — если судить вот по этому бредовому утверждению.

оконные менеджеры испокон веков писались на тормозах разных сортов и ни разу это не становилось проблемой

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

I>>Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.
I>>При чем тоже самое и в россии и в любой из стран бывшего ссср.
S>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

Кто ж виноват вашей специфике ?

I>>А у меня все просто — вуз где я учился ведущий в своем профиле. Как ты понимаешь, это много чего меняет.
S>Конечно ничего не меняет. ВУЗ о котором я пишу (кстати, вот здесь) — тоже ведущий в своем роде, в подготовке кадров для ядерного центра. Не хухры-мухры

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

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

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

S>>Я что тут, тебя поудивлять захожу?

I>У меня такое ощущение, что да, ты заходишь поудивлять особенностями твоего умения читать, чегото видеть и тд.
Ну тогда ладно, удивляйся дальше.

I>Проблемы не в конкретном вузе, а в абитуриентах которые идут в ИТ-специальности в странах бывшего СССР не все в порядке, из них 90% знают математику крайне плохо, ансктолько плохо что делают массу ошибок в вычислениях.
Идут-то ладно, как же они попадают в эти ВУЗ-ы? Ты все увиливаешь от ответов на тему экзаменов...

I>Представь себе, для этого не надо учиться в каждом из вузов по 5 лет. Из вузов бывшего СССР где есть ИТ специальности можно вообще разогнать 3/4 и это ничего не изменит
Ну как же не изменит? Изменит. Тогда 3/4 не получат диплом о в/о, за которым собственно они туда пошли.

S>>Да-да, а в вступлении SICP написано что успешно применялся для обучения людей, большей частью не знакомых с программированием, да, аж с 70х годов.

I>Посмотри что там за вузы были и какой там контигент.
Нормальный контигент такой.

I>>>Нет, и никогда не был.
S>>И чем же он тогда по-твоему был?

I>Азы программирования, а функциональщина задвигается специальным предметом, перед которым sicp является обязательным.
С тем что это АЗЫ — я согласен. А с тем что это не функциональные азы — нет.

S>>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%81%D1%88%D0%B0%D1%8F_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0

I>Это все так себе, большая часть этого хлама просто школьная математика. Высшая она сильно условно.
Ну это смотря для кого. Как всегда, составители программы для ВУЗ-ов и википедии забыли спросить твоего мнения.

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

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

S>>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

I>Кто ж виноват вашей специфике ?
точно не я

I>Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.
А я и не говорил что он близко ИТ. Зато там есть электротехника и всегда найдется полпотока тупых

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

V>>Это фундаментальное св-во операции ветвления. В любой точке ветвления необходимо иметь уже вычисленный аргумент-предикат. Поэтому, точки ветвления в алгоритмах обычно называются узлами, т.к. каждое ветвление означает конец предыдущего этапа вычислений. Поэтому, пофиг даже как лично ты эту формулу воспринимаешь. Она пошаговая по свой природе.

A>def x = sin(42);
A>def y = x * 2; // для вычисления y необходимо иметь уже вычесленный x

A>Функционального программирования не существует. (С)
A>Опровергни


Покажи ветвление.

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


V>>Это фундаментальное св-во операции ветвления. В любой точке ветвления необходимо иметь уже вычисленный аргумент-предикат. Поэтому, точки ветвления в алгоритмах обычно называются узлами, т.к. каждое ветвление означает конец предыдущего этапа вычислений. Поэтому, пофиг даже как лично ты эту формулу воспринимаешь. Она пошаговая по свой природе.
S>Полная чушь. Никакой фундаментальности тут нет.

Боюсь, доказать ты это не сможешь. А я уже доказывал рядом не раз. См. что есть if в комбинаторном базисе I/K.


S>Домашнее задание:
S>1. выяснить, как работает ускоренная схема арифметического сложения, понять, почему там аргументы вычисляются до предиката, а не после.

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

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


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

Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?

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


S>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.

Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
Хорошо себя чувствуешь?

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

V>>Это фундаментальное св-во операции ветвления. В любой точке ветвления необходимо иметь уже вычисленный аргумент-предикат. Поэтому, точки ветвления в алгоритмах обычно называются узлами, т.к. каждое ветвление означает конец предыдущего этапа вычислений. Поэтому, пофиг даже как лично ты эту формулу воспринимаешь. Она пошаговая по свой природе.
S>Пошаговая как и WHERE в SQL

Увы, в where не говорится, как получить результат, а только описывают характеристики результата. SQL-выражение является аналогом исходного уравнения. Зато некая последовательность операций РА вполне может являться решением уравнения, заданного в SQL. Эту последовательность операций РА можно будет разложить на шаги проще простого.

V>>На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?
S>В курсе SICP рекурсию дают на лекции 1.

Этот курс даётся на базе уже некоторого предварительного образования, то бишь читается не на 1-м курсе. В любом случае, речь как минимм о людях, уже закончивших школу.


V>>Враки опять. Не научив декомпозиции, не научишь рекурсии, это аксиома. Получается замкнутый круг, т.к. сама цель обучения на вводном курсе — это обучение декомпозиции задач (в итоге декомпозиции данных и алгоритмов по их обработке). В итоге, банальную рекурсию можно понять лишь ближе к концу вводного курса. Некрасивая кривая обучению выходит.
S>Ближе к началу второй половинки 1-ой лекции

И че? На 3-м курсе на первых же лекциях по устройству ОС давали все популярные примитивы синхронизации. Значит ли это, что такую лекцию поймет ученик, скажем, 5-6-го класса?


V>>Лучше устыдись своего примера насчет чисел Фибоначи. Исходная формула описывает получение следующих элементов ряда из предыдущих. Т.е. вместо твоего стыда надо было так:
V>>F[n] = F[n-1] + F[n-2],
V>>где F никакая не ф-ия, а значение элемента ряда.
S>То что F не функция, тебе придется показать формально.

Мне не надо никому ничего показывать, я так ставлю условие задачи, вводя отношения м/у [i]элементами ряда, а не м/у ф-иями, описывающими эти элементы. Прочувствуйте разницу, как говорится. И, хотя формально это одно и то же (ведь символьная подстановка ничего не меняет), но в моем случае рассуждение отталкивается от конкретных значений элемента ряда, в то время как в варианте ф-ии F(x) присутствует дополнительная абстракция — подстановочный символ. Итого, до изучения основ декомпозиции, ученик эту задачу не решит в первом варианте, зато решит в моём. Помня себя, когда-то впервые увидев Бейсик в школе, я решал подобные задачи уже через 5 мин после изучения 4-х основных операторов Бейсика и нащелкал подобных задач к концу урока чуть ли не с десяток. Как раз упоминавшаяся задача с решением квадратного уравнения была первой. То бишь, я еще понятия о декомпозиции не имел, но уже "схватил", как всё работает и как этим орудовать, извлекая некую пользу и имея возможность выводить на печать результаты промежуточных вычислений. В ФП это невозможно.

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

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

Далее. Берем лямбды. Лямбда не может вызывать себя рекурсивно. Т.е. уже на совсем ранних уроках по ФП необходимо какое-то понимание из раздела комбинаторики ф-ий (как минимум Y-комбинатор) для целей построения банальных циклов "по-месту". А это опять и снова требует некий далеко ненулевой бэкграунд (попробуй объяснить ребенку это). А ведь речь по-прежнему о банальном цикле, который в императивном Бейсике/Паскале можно писать "по-месту" безо-всяких знаний о декомпозиции и комбинаторике.

Кароч, если речь всё еще об обучении детей, то тут даже обсуждать нечего. ФП непригоден для неподготовленных людей.

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

S>Даже если не пользоваться group by с having и подзапросами, а только джойнами, where и order by, то вы употеете делать аналогичную "чисто выборку данных" на императивном языке.

Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))

S>А обеспечение ACID для типичной OLTP-транзакции вам будет стоить седых волос в неожиданных местах.

Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.


S>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать мало-мальски интересных инвариантов.

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

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

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

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

A>>def x = sin(42);
A>>def y = x * 2; // для вычисления y необходимо иметь уже вычисленный x

A>>Функционального программирования не существует. (С)
A>>Опровергни

V>Покажи ветвление.
Зачем?

Вот тут

Автор: vdimas
Дата: 09.10.12

ты пишешь:

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе

Далее ты говоришь, что операция ветвления "пошаговая по свой природе". Т.е. операций ветвления не может быть в ФП, так?

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

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

S>Замечательно. И что, вы полагаете, что реальные индивидуумы в реальной жизни действуют именно по этому алгоритму?

Угу, особенно если покупки делает сильная половина по заданию своей прекрасной половины. ))


S>Тогда я вас разочарую — нет, не действуют они по этому алгоритму. Реальный алгоритм там очень fuzzy, и включает массу неэффективностей и повторов.

Т.е. всего лишь чуть сложнее алгоритм, но суть та же. Человек не может осмотреть все продукты одновременно и одновременно принять все решения. Только пошагово.


S>И это при том условии, что у человека есть заранее подготовленный список покупок. Часто его нет, и покупки производятся исходя из программы типа "чего-нибудь на ужин".

Дык, поменяй предикат при if. Принципиально ничего не изменится.

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

S>>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать маломальски интересных инвариантов.

I>Ну ладно, с лотком ты прав

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

Говнодрайвер? — Да.
Виноват императив? — Нет, ес-но. Виноват говнопрограммер.

I>оконные менеджеры испокон веков писались на тормозах разных сортов и ни разу это не становилось проблемой

Вообще-то становилось. Ужасный линухово-юниховый гуй всегда был притчей во языцех. Зато у вынь и мак системный гуй всегда вылизан до идеальности в плане перформанса. В виндах состояние очереди сообщений к окошкам (к потоку, если быть точным) даже влияет на решения шедуллера.

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

S>Иперативное программирование отличается от, скажем, функционального вовсе не тем, что оно "указывает, что делать". Оно оперирует изменяемым состоянием некоторого вычислителя. SQL, к примеру, тоже "императивен" в том смысле, что у него все стейтменты представляют собой глаголы в повелительном наклонении. Однако это никак не влияет на его декларативную природу.

Кстате, вот сам же себя только что опроверг, когда ты отрицал, что декларативность — это скорее взаимоотношение уровней абстракций, чем независимое св-во. В этом смысле UPDATE table из SQL точно так же декларативен как printf() в С++, потому что точно так же задаёт, ЧТО надо делать, а не КАК... Более того, не смотря на всю "чистоту" и "декларативность" каждого SQL-выражения в отдельности, последовательность SQL-выражений составляет несомненно императивную программу над состоянием базы. Как тут принято в последнее время — муахаха... ))

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

V>Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))
А ещё все программы на десктопе исполняются вообще одним и тем же процессором с одной и той же системой команд, и она, естественно, императивна.
Этого достаточно, чтобы понять, почему ваш аргумент не имеет в данном контексте никакого смысла, или нужно разжевать?
V>Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.
И здесь вы опять путаете тёплое с мягким, т.е. формулировку задачи с её решением.

V>Какая восхитительная чушь. Тебе врожденную эквивалентность ЛИ и МТ напомнить или сам догадался уже? А то, что уровни описания подробностей задач в императиве и на современных ФП-языках одинаковы тоже напомить? При чем тут инварианты, если речь всего-навсего о том, что не ввели промежуточные состояния в АПИ — "закрытие в процессе", "открытие в процессе"? Эти промежуточные состояния точно так же могли не ввести в ФП-программу... И кстате, драйвер обрабатывает сообщения из произвольных физических потоков в кольце ядра, то бишь, требуется совместный доступ к расшаренным данным (флагам) из нескольких потоков. Как это сделать на ФП? )))
Омг, омг. Столько чуши в одном абзаце, прямо праздник какой-то. Даже не знаю, на что прокомментировать. Ну, на последнюю фразу отвечу: вот вам, скажем, слово Эрланг что-нибудь говорит? В нём и есть ответ, как сделать обработку сообщений "из произвольных физических потоков" на ФП. А то, что для этого нужен "совместный доступ к расшаренным данным" — это вы уже сами придумали, и сами над собой посмеялись.

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

V>Какая из них? Классическая ускоренная схема сложения (и умножения) не содержит предикатов вообще, а просто распараллеливает операцию переноса, чтобы превратить линейное набегание задержки срабатывания вентилей в логарифмическое.
Совершенно верно. Про "не содержит предикатов вообще" — это вы сильно высказались. Вам понятно, что для сложения блока разрядов есть две ветки — с наличием переноса и без него? По вашей логике это бы означало, что надо непременно дождаться вычисления переноса, а уже потом вычислять результат.
К счастью, так никто не делает.

V>Или ты имел ввиду переупорядочивание + спекулятивные вычисления в современных процах? Это не есть ускоренное сложение, это именно спекулятивные вычисления, которые могут иметь место в случае наличия свободных ресурсов внутри проца (свободных арифметических блоков). В общем, это не принципиально для обсуждаемого, т.к. результаты неверной ветки отбрасываются (либо сбрасывается конвейер). Не принципиально потому, что в проце нет никакой рекурсии и быть не может... в отличие от ФП, где одна из веток обычно останавливает рекурсию. Без упорядочивания вычислений на ветвлении ты получишь зацикливание уже на банальной ф-ии вычисления факториала.
Ну, вот видите, от "фундаментального" требования, т.е. выполняемого всегда, мы внезапно перешли к "обычно".
Кстати, вас не затруднит продемонстрировать мне "получение зацикливания" на вычислении факториала?

V>Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?
S>>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.
V>Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
V>Хорошо себя чувствуешь?
Я — прекрасно. Вы уже нашли этот случай, правда, не смогли этого заметить. Действительно, без ычисления предиката можно обойтись тогда, когда выбираемые ветки одинаковы. Чтобы вы не продолжали нести чушь про неисправный компилятор, я вам на пальцах поясню, откуда могут возникать такие случаи.
Поскольку в ФП функции являются "гражданами первого класса", наш код не обязан иметь полностью статическую структуру. Некий алгоритм может быть сформулирован для общего случая, и параметризован функциями. Для частных применений параметры могут быть в том числе и одинаковыми. Ну вот, скажем, дурацкий пример — имеем алгоритм раскраски таблицы в UI. В общем случае мы имеем разные цвета для чётных/нечётных строк, в частном случае конкретной дизайн-схемы мы скармливаем в него "белый"/"белый".
В итоге вычисление предиката внутри общего кода становится избыточным.

Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.

А ваши аргументы на эту тему я уже читал — и в прошлый раз они были вполне смехотворны. Вы пускаетесь в рассуждения о производительности, которые на микроуровне вообще не имеют смысла — потому, что в реальном случае мы имеем не изолированный предикат, а более-менее сложную функцию, скомбинированную из других функций, и так далее. И здесь оптимальный порядок вычислений "листьев" может быть нетривиальным.
Вы же в курсе, почему современные ФП-языки ведут себя лучше, чем Шлемиель, при порождении ряда Фибоначчи, несмотря на явно рекурсивное описание?
Ну и это же является намёком на то, что не имеет смысла говорить о конкретном императивном решении для вычисления отдельной функции. Вычислитель не обязан быть "всегда энергичным" или "всегда ленивым". Это же ФП — отсутствие побочных эффектов даёт нам свободу в упорядочивании.

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

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

S>Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.
+1

Более того, если одна из F1/F2 будет (_|_), то ничего страшного не должно произойти. Ошибка будет, если (_|_) передастся в функции IO, после того, как по предикату выберется эта ветка.

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

V>Покажи ветвление.

Вот, кстати, скажи, здесь есть пошаговость:

abs(x) { if x<0 -x else x }

?

А тут:

abs(x) { 
  def b = (x < 0) :> int; // Cast
  b*(-x) + (1-b)*x 
}

?

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


V>>А то, что уровни описания подробностей задач в императиве и на современных ФП-языках одинаковы тоже напомить?

Кстате, от ответа на этот вопрос ты старательно уходишь уже 3-й раз на моей памяти.


V>>При чем тут инварианты, если речь всего-навсего о том, что не ввели промежуточные состояния в АПИ — "закрытие в процессе", "открытие в процессе"? Эти промежуточные состояния точно так же могли не ввести в ФП-программу...

И на единственное техническое замечание по самому драйверу тоже ес-но ответить нечего. ЧТД.


И кстате, драйвер обрабатывает сообщения из произвольных физических потоков в кольце ядра, то бишь, требуется совместный доступ к расшаренным данным (флагам) из нескольких потоков. Как это сделать на ФП? )))
S>Омг, омг. Столько чуши в одном абзаце, прямо праздник какой-то. Даже не знаю, на что прокомментировать.

Дык, ты уже последние полсотни постов не знаешь что комментировать. Тема зачетная. Упёрся в тупик, однако...


S>Ну, на последнюю фразу отвечу: вот вам, скажем, слово Эрланг что-нибудь говорит? В нём и есть ответ, как сделать обработку сообщений "из произвольных физических потоков" на ФП.

ЧТД. Очередное проявление твоей поверхностности. Медитировать на выделенным до бесконечности.


S>А то, что для этого нужен "совместный доступ к расшаренным данным" — это вы уже сами придумали, и сами над собой посмеялись.

Я-то прекрасно знаю, над чем я смеюсь. Тут кто-то на весь интернет показывает своё невладение даже базовыми механизмами работы современных ОС на SMP-машинках. За Эрланг отдельное спасибо. Можно было с тем же успехом предложить Оберон или Барток как язык для исходника драйвера под вполне конкретную названную ОС. Возьми себе за труд хоть немного порассуждать в эту область, глядишь, и понял бы, в чем именно заключается мой вопрос.

Ну что? Еще одна попытка?

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

V>>Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))
S>А ещё все программы на десктопе исполняются вообще одним и тем же процессором с одной и той же системой команд, и она, естественно, императивна.
S>Этого достаточно, чтобы понять, почему ваш аргумент не имеет в данном контексте никакого смысла, или нужно разжевать?

Кстате да, нужно разжевать.
1. Предложить архитектуру вычислителя, заточенную под ФП (алу, память и особенно интересует непротиворечивый ввод/вывод, работающий во времени);
2. Пояснить, почему когда речь об юзер-левельной программе на ЯВУ, тебя вообще интересует архитектура процессора? Ты ж сам многократно утверждал, что для ФП доступно больше анализа/оптимизаций.

Правда, последние исследования в области суперкомпиляции с треском опровергли это заблуждение — таки в терминах регистров удаётся суперкомпилировать куда как глубже, чем в случае продвинутой бета-редукции, которую раньше по ошибке называли суперкомпиляцией... но бог с ним, меня имтересуют твои рассуждения, ты же откуда-то берешь свою веру, чтобы здесь её проповедовать? Дык, поясни.


V>>Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.
S>И здесь вы опять путаете тёплое с мягким, т.е. формулировку задачи с её решением.

Да нет, я лишь напоминаю, как именно решаются задачи в императиве и почему именно так. А то вы что-то много изобретать последнее время изволите того, чего реально нет и не предвидится в ближайший пару десятков лет как минимум. А на деле мне регулярно приходится разрабатывать высокоскоростные in-memory хранилища и АПИ запросов к ним на императивном языке. Дык, я же прекрасно вижу, что когда речь о заведомо определённой структуре данных, то у декларативного SQL нет никаких преимуществ.... Т.е. вообще никаких — одно сплошное неудобство в плане сопряжения с остальной программой + лишние накладные расходы для этого. К тому же, напрочь отрубается любая статическая оптимизация запросов (всё на инлайнах и шаблонах, ес-но).

В общем, для какой-нить консоли админа базы SQL хорош, сугубо для REPL, но для современной программы это заведомо чужеродный элемент. Отсюда и выплывают такие уродцы, как Hibernate или LINQ, лишь бы не SQL.

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

V>>Какая из них? Классическая ускоренная схема сложения (и умножения) не содержит предикатов вообще, а просто распараллеливает операцию переноса, чтобы превратить линейное набегание задержки срабатывания вентилей в логарифмическое.
S>Совершенно верно. Про "не содержит предикатов вообще" — это вы сильно высказались. Вам понятно, что для сложения блока разрядов есть две ветки — с наличием переноса и без него?

Гы, ну да, любая схема — это некое материализованное логическое выражение по-определению! сильно сказано!

Хотя, я догадываюсь, что ты имел ввиду... (сам придумал как программист-практик по аналогии в многопоточными распараллеленными вычислениями? или тебя кто-то обманул?)

В общем, в реальности сумматоры делают на блоках ускоренного переноса, см. его схему или логическую формулу. Это просто "широкая" логическая схема, которая формирует признак переноса на блок разрядов (рекомендую внимательно изучить хотя бы первые 3-4 слагаемые в ДНФ логического выражения схемы ускоренного переноса... хотя бы эрудиции ради). Обычно группируют по 4 разряда, те группы опять берут по 4 разряда и т.д. до достижения требуемой разрядности.


S>По вашей логике это бы означало, что надо непременно дождаться вычисления переноса, а уже потом вычислять результат.

Ты не поверишь! )))
Да, имено так оно в реальности и работает. Это не моя логика, это так устроен твой процессор, с помощью которого ты написал и отослал свой пост (и вообще любой сумматор на любом проце). Потому что одноразрядный сумматор состоит из 3-х равнозначных входов, т.е. пофиг, какой из входов является признаком переноса. Эти переносы подаются на целевые одноразрядные сумматоры одновременно, как результат работы схемы ускоренного переноса. Вот такая фигня, малята...

В общем, я догадался, что за схему ты имел ввиду, но "распараллелив" вычисления на твоей схеме, ты меньше выиграешь на последующих мультиплексорах хотя бы потому, что стоимость переключения мультиплексора ничуть не меньше стоимости работы одноразрядного сумматора. Итого, ты нам предложил минимум удвоение задержек... Хотя, согласен, тоже убежал от линейного их распространения.

S>К счастью, так никто не делает.

Да когда б ты уже отучился делать заявления, одно смелее другого?
Тебя же люди читают...


V>>Или ты имел ввиду переупорядочивание + спекулятивные вычисления в современных процах? Это не есть ускоренное сложение, это именно спекулятивные вычисления, которые могут иметь место в случае наличия свободных ресурсов внутри проца (свободных арифметических блоков). В общем, это не принципиально для обсуждаемого, т.к. результаты неверной ветки отбрасываются (либо сбрасывается конвейер). Не принципиально потому, что в проце нет никакой рекурсии и быть не может... в отличие от ФП, где одна из веток обычно останавливает рекурсию. Без упорядочивания вычислений на ветвлении ты получишь зацикливание уже на банальной ф-ии вычисления факториала.
S>Ну, вот видите, от "фундаментального" требования, т.е. выполняемого всегда, мы внезапно перешли к "обычно".

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


S>Кстати, вас не затруднит продемонстрировать мне "получение зацикливания" на вычислении факториала?

Издеваешься?

uint fact(uint arg) {
  if(x < 2)
    return 1;
  else
    return arg * fact(arg - 1);
}

При вычислении второй ветки раньше предиката (x<2), легко уйти в вечный цикл. Предложи непротиворечивую логику по ограничению потребления ресурсов такими "ложными" вычислениями на уровне компилятора?


V>>Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?
S>>>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.
V>>Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
V>>Хорошо себя чувствуешь?
S>Я — прекрасно. Вы уже нашли этот случай, правда, не смогли этого заметить.

Нет, это я тебе показал, как ты ходишь вокруг одного и того же.

S>Действительно, без ычисления предиката можно обойтись тогда, когда выбираемые ветки одинаковы. Чтобы вы не продолжали нести чушь про неисправный компилятор, я вам на пальцах поясню, откуда могут возникать такие случаи.

Не надо метать тут банальности. В любом случае, где предикат НЕ нужен и это понятно ДО вычисления, компилятор должен его выкидывать, а не пытаться исполнять две ОДИНАКОВЫЕ ветки в произвольном порядке.

S>Поскольку в ФП функции являются "гражданами первого класса", наш код не обязан иметь полностью статическую структуру. Некий алгоритм может быть сформулирован для общего случая, и параметризован функциями. Для частных применений параметры могут быть в том числе и одинаковыми. Ну вот, скажем, дурацкий пример — имеем алгоритм раскраски таблицы в UI. В общем случае мы имеем разные цвета для чётных/нечётных строк, в частном случае конкретной дизайн-схемы мы скармливаем в него "белый"/"белый".
S>В итоге вычисление предиката внутри общего кода становится избыточным.

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

В этом краеугольный камень всех рассуждений. Да, я итак знаю, что одну и ту же семантику можно выразить многими способами. Но если компилятор не способен полностю "понять" семантику происходящего в разных ветках, то единственно что ему остаётся — это "честно" выполнить скормленный ему код. Причем, все эти рассуждения верны как для императива, так и для ФП (энергичного и ленивого в т.ч.).

S>Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.

Ес-но. Речь только о том, сколько оборотов от 0-ля до UInt::MaxValue прокрутит приведенный факториал, используя каждый раз ложную ветку, прежде чем "кто-то третий" его остановит. )))

S>А ваши аргументы на эту тему я уже читал — и в прошлый раз они были вполне смехотворны. Вы пускаетесь в рассуждения о производительности, которые на микроуровне вообще не имеют смысла — потому, что в реальном случае мы имеем не изолированный предикат, а более-менее сложную функцию, скомбинированную из других функций, и так далее. И здесь оптимальный порядок вычислений "листьев" может быть нетривиальным.
S>Вы же в курсе, почему современные ФП-языки ведут себя лучше, чем Шлемиель, при порождении ряда Фибоначчи, несмотря на явно рекурсивное описание?
S>Ну и это же является намёком на то, что не имеет смысла говорить о конкретном императивном решении для вычисления отдельной функции. Вычислитель не обязан быть "всегда энергичным" или "всегда ленивым". Это же ФП — отсутствие побочных эффектов даёт нам свободу в упорядочивании.

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

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

И да, сравнение со спекулятивными вычислениями внутри проца — это плохое сравнение. Плохое хотя бы потому, что в проце сплошная динамика. Шедуллер команд располагает сведениями, какая ячейка памяти сидит в кеше какого уровня и сидит ли вообще, есть ли свободные АЛУ и т.д. и т.п. Всё это "по месту" и всё это однократно, без рекурсий. Другое дело компилятор, у которого только статическая информация и который должен генерить код, подходящий для совершенно разных мгновенных условий. Именно отталкиваясь от статической компиляции я утверждаю, что все эти вещи дальше рассуждений в обозримом будущем пойти не могут. Именно так, несмотря на твои повторы одних и тех же банальностей об отсутствии побочных эффектов. Ты ведь не Америку каждый раз открываешь, твердя про отсутствие побочных эффектов, скорее, ровно наоборот. Имею ввиду, что в любом современном компиляторе с ФП-языка такое поведение, будь оно замечено, будет помечено как баг и обязательно исправлено. Се ля ви.