Ответ на »сообщение 3295« (Илья Ермаков)
___________________________

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

Не понял этой мысли. Что придётся считать по новой?
Таблицу решений, аналогичную Вашей, но не изменяющуюся в данной задаче?
Зачем? При загрузке программы она один раз просчитается (инициализация переменной = однократное присваивание) - и достаточно.


Да еще подозрительная фраза Geniepro про то, что генерируются дублирующие результаты, которые надо фильтровать... Я подозреваю, что при чистых Ф-решениях такая избыточность-фильтрация будет происходить часто, всего лишь из-за невозможности разделить расчеты на шаги и запомнить промежуточные вычисления.

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

list comprehensions - это способ генерации списков по заданному правилу.
Вот простейший пример:

[1..100]   

Получаем список из 100 чисел от 1 до 100.
Более сложный случай:

[ x | x <- [1..100],
      x `mod` 3 == 0 ]     

Тут мы получаем список таких чисел из диапазона от 1 до 100, которые делятся на 3 без остатка.
Подходим теперь к нашему случаю.

[ m ++ p |  m <- [ "A", "B", "O" ],
            p <- [ "A", "B", "O" ] ]       

Тут мы получаем список строк:

[ "AA", "AB", "AO", "BA", "BB", "BO", "OA", "OB", "OO" ]   

Как видите, мы тут видим комбинации, повторяющиеся по смыслу данной задачи:
"AB" и "BA", "AO" и "OA", "BO" и "OB". Функция allels'from'ABO, принимая эти повторяющиеся варианты, выдаст также повторяющиеся и совпадающие результаты:

[ "A", "AB", "A", "AB", "B", "B", "A", "B", "O" ]   

Тут уже по три раза встречается результаты "A" и "B", и два раза - "AB".
Вот эти-то повторяющиеся результаты и пришлось отсеивать функцией sieve, которую я написал зря (она дублирует стандартную функцию nub). После отсеивания повторов получаем список

[ "A", "AB", "B", "O" ]

Вот и всё... Не так уж и страшно...

ЗЫ. В реальной программе брались не наборы [ "A", "B", "O" ], а те наборы аллелей, которые есть в крови родителей и заранее неизвестны.
Можно было бы наворотить более сложный способ, не порождающий ненужные повторы - но вряд ли это было бы намного быстрее, если вообще было бы быстрее... Типа Вашей таблицы вариантов...
Это вполне возможно, но зачем в данной простой задачке? В сложных же задачах будут использоваться какие-нибудь хитрые решения типа хеш-таблиц и т.п.

Ответ на »сообщение 3293« (Илья Ермаков)
___________________________
А в принципе, весь код решения можно оформить на Обероне и в виде чистых функций.
Однако выгоднее построить карту решений, из которой потом для каждой строчки входного файла их извлекать. Кроме того, после построения карты прямых решений карта обратных легко строится по ней.
В приведенном решении на Хаскелле для каждого запроса придется все считать по новой.
А если blood.in состоит из миллиона повторяющихся запросов, хаскелевое решение очччень крупно пролетит по времени. Да еще подозрительная фраза Geniepro про то, что генерируются дублирующие результаты, которые надо фильтровать... Я подозреваю, что при чистых Ф-решениях такая избыточность-фильтрация будет происходить часто, всего лишь из-за невозможности разделить расчеты на шаги и запомнить промежуточные вычисления.
А как вы будете выкручиваться из положения на задачах динамического программирования, где вся "изюминка" - в запоминании результатов промежуточных расчетов?
Опять монады - с эмуляцией императива!

Ответ на »сообщение 3293« (Илья Ермаков)
___________________________
А процедуры ExtractCase, InitInverseMap с двойными вложенными циклами и впихиванием чего то там в массив ?
Да и вывод то на хаскеле занял всего строчек 10 противу ваших черт те знает сколько.
А еще говорят что императив в хаскеле тяжелей :))

Вряд ли вы сможете отрицать что состояние размазано у вас в программе горааааздо шире чем в хаскелевской.
Вопрос: Потому что это было необходимо для решения задачи ? Потому что вас так научили ? или потому что инструмент заставляет ?

Ответ на »сообщение 3292« (Jack Of Shadows)
___________________________
Джек, если Вы присмотритесь повнимательнее, то заметите, что уйма локальных переменных и "записей-стираний" во второй половине программы, которая отвечает за ввод-вывод строк. Это пример того, что со строками в ФЯ работать действительно гораздо удобнее.

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

Ответ на »сообщение 3289« (Руслан Богатырев)
___________________________
Подписи в обходном листе не зачеркивают и не пишут на их месте новые.
Я согласен, алегория не полная конечно.
Я всего лишь хотел сказать что в ИЯ программист сам бегает с каким то листочком на котором постоянно делает какие то пометки (записывает сотояние в локальные переменные)

В то время как в чистом ФЯ ему этого делать не приходится, ну или приходится в на очень маленьком и строго ограниченном участке программы.
Посмотрите на приведенный GeniePro код. Более 80% кода программы - чистые преобразования, никакого состояния вообще.
И только в трех функциях - точка входа main, чтение с файла и распечатка, идет работа с состоянием.
А потом сравните с кодом Ильи. Десятки локальных переменных в которые на каждой второй строчке программы чего то мелкое записывается, перечеркивается, записывается заново.
Такой код называется write only. То есть пока пишешь все понимаешь. А как застыло - без поллитры не разберешь :))

Ответ на »сообщение 3284« (Руслан Богатырев)
___________________________

Насколько я знаю, карринг (currying) -- это просто сведение обработки функции от n-аргументов к конкатенации n-функций от одного аргумента. При этом разбиение на несколько функций происходит так, что функция применяется к ближнему левому аргументу. Принцип принадлежит американскому математику Хаскелю Карри (Haskell Curry), в честь которого язык Haskell и назвали.

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

Ответ на »сообщение 3283« (Руслан Богатырев)
___________________________

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

Что-то моя провокационная фраза даже не вызвала никаких возражений. :)

Ответ на »сообщение 3288« (Jack Of Shadows)
___________________________

В ФЯ состояние это как эстафетная палочка которая передается от одного игрока к другому.

А игроки -- функции? Тогда, наверное, все же не эстафетная палочка, а фотка. Ведь у инициатора вызова палочку не забирают.

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

Подписи в обходном листе не зачеркивают и не пишут на их месте новые. В ИЯ состояния локализуются в процедурных блоках (головные процедуры, обычные процедуры). Это своего рода "доска с ключами" к комнатам в гостинице, доступ к которой обеспечивает портье. Только вот досок таких -- по числу гостиниц (процедур). А портье не всегда может за всеми посетителями уследить. :)

Ответ на »сообщение 3283« (Руслан Богатырев)
___________________________
Таким образом, общая схема программы в ФП -- набор трансформаций, обусловленных композицией функций. Так что же есть состояние в ФП и есть ли оно?

В ФЯ состояние это как эстафетная палочка которая передается от одного игрока к другому.
В то время как в ИЯ состояние это "обходной лист" на который нужно собрать подписи, бегая из одного кабинета в другой.
В случае с эстафетной палочкой, программист просто расставляет игроков, дает палочку первому - и понеслась.
В случае с обходным листом, программист САМ бегает с ним от инстанции к инстанции.

Ответ на »сообщение 3282« (info21)
___________________________

Не очевиден алгоритм в целом -- локально все понимается без проблем (почти -- для незнакомых конкретно с КП).
Для локального понимания хаскелевского варианта нужно знать гораздо больше.

А каков смысл понимания каждой отдельной строчки если общая цель задачи недоступна пониманию ?
В ИЯ действительно каждую отдельную строчку может читать и легче. Но вермишель из этих строчек ну очень тяжел для "процеживания".
В ФЯ (особенно в чистом как хаскель) да, каждая отдельная строчка плотнее, ее тяжелее читать. Но зато ВСЯ программа читается и понимается практически с первого раза, как проза.
Оно и понятно почему. Ведь вы читаете ОПИСАНИЕ задачи, а не последовательность шагов для ее выполнения.
Не нужно ментально постоянно отслеживать где и что в какой момент поменялось.