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

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

Если Вам нужен алгоритм максимально быстрого вычисления чисел Фибоначчи рекурсивным способом, то вот неоднократно уже приводившаяся функция (на Хаскелле):

fib n = fibt n 0 1
  where
    fibt 1 _    curr = curr
    fibt n prev curr = fibt (n-1) curr $!(prev+curr)

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

Функцию Вашего знакомого обдумать надо - почему у неё после n=37 происходит такая катастрофическая потеря точности. Но в любом случае, даже если реализовать плавающую арифметику с, например, миллионом цифр в мантиссе, быстрее простого целочисленного варианта точно не будет, и при этом опять же точные результаты будут даваться только до определённого значения n, а после него опять произойдёт резкий рост погрешности...
Может быть аналитически эта функция и верна, но непрактична однозначно...

>>>А где Вы взяли эту нестандартную формулу? Она вообще неправильно работает
>>>(после n=37) и это не связано с HUGS.
>>>Чем Вас не устраивает эта:
Подсказал один знакомый математик :))). Кстати, к формуле он приложил ее строгий аналитический вывод на 2 листах :). Одно из двух - или у него ошибка в доказательстве этой формулы, или у Вас.
А причина простая - зашел у нас разговор о типах рекурсии, о функциональном программировании, о качестве алгоритмов и тд, итп... Вот и вышли мы на числа Фибоначчи (классика, однако). И я предложил ему подумать, как можно вычислить F(n) на основе простой рекурсии и будет ли это более эффективным решением, чем "алгоритм ленивого списка" по критерию времени.

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

Это в отличии от ИЯ, где просто придется создавать новые функции, новые библиотеки, каждый раз когда задача немножечко меняется, и так до тех пор пока не получается невероятно раздутый PL/1 или java SDK или dotnet framework.

Всем известная функция map прогоняет список данных через функцию

map (*2) [1,2,3,4]

Output: [2,4,6,8]

А вот как прогнать список функций над одним значеним ?
Казалось бы надо писать новый map который будет принимать 1 значение и список функций, который она будет вызывать с этим значением.

На самом деле все невероятно просто и красиво. Пример:

map ($ 3) [(+5), (*4), (^2)]

Output: [8,12,9]

Ответ на »сообщение 1896« (Geniepro)
___________________________
Это другое. Там меняется полностью структура списка, но при это ни обин обьект внутри списка не копируется,
Скажем если вы отсортируете список тяжелых обьектов типа "автомашина", то несмотря на то что получите новый список, в нем будут не копии машин а они сами (ну вернее ссылки на них). Обьекты внутри списка все равно не копируются.

Далее, во многих случаях и сам список не создаеся заново.

Скажем
append x y = x ++ y
Это не означает что списки x и y будут скопированы в новый список который функция append вернет.
Просто в новом списке после последнего элемента из х будет идти ссылка на голову y
То есть не только обьекты из списка y не копируются но и сам список не создается заново.

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

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

Приведите пример когда по вашему в чистом ФЯ может произойти копирование данных вместо передачи по ссылке.

Вообще-то справедливости ради надо вспомнить о том оверхеде из-за копирования подсписков при упрощённой сортировке списков (видимо, это и имеет в виду hugi).
Сортировка массивов в ИЯ (с изменением самих массивов) не приводит к копированию подмассивов, хотя там тоже в любом случае копируются отдельные элементы массивов.

Говорят, в Clean эта проблема решена уникальными (unique) классами, которые позволяют некоторым потокам внутри себя изменять состояние массивов, что позволяет очень быстро их обрабатывать. При этом эти изменения невидны снаружи (примерно как в монадах в Хаскелле).

Ответ на »сообщение 1891« (hugi)
___________________________
Geniepro вам уже ответил.
Ну а чтобы лучше понять, поробуйте на практике.
Приведите пример когда по вашему в чистом ФЯ может произойти копирование данных вместо передачи по ссылке.

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

Можно ли реализовать арифметику чисел с большой разрядностью мантиссы в Haskell (Hugs).

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

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

Ответ на »сообщение 1886« (Jack Of Shadows)
___________________________
>>>undefinedС чего вы взяли ?

А как ещё обеспечить неизменяемость?

Если функция чиста (как, например, в Хаскелле, Clean), то она в принципе не может изменять свои параметры или какие-то глобальные переменные.

Так зачем их копировать, если их можно передать по ссылке?

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

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

А где Вы взяли эту нестандартную формулу? Она вообще неправильно работает (после n=37) и это не связано с HUGS.

Чем Вас не устраивает эта:

f n = (((sqrt 5 + 1) / 2)^n - ((sqrt 5 - 1) / 2)^n) / sqrt 5

У этой формулы проблем нет...


С целыми числами Hugs работает независимо от разрядности (реализует арифметику "больших" чисел). А вот с плавающей точкой получается предел ~15 значащих разрядов для Double.

Вообще, это предел не вычислений, а именно вывода, похоже. Особенность библиотек вывода на печать (функции show у типа Double, который является экземпляром класса типов Show).
Расчёты-то по-любому идут в арифм. сопроцессоре с его погрешностью.
Вопрос, конечно, интересный...
В GHCi/GHC этот предел 16-17 цифр при выводе результата.
Вообще, у 64-битных вещ. чисел количество значащих цифр должно быть около 19. Почему результаты при выводе округляют - непонятно.


Можно ли реализовать арифметику чисел с большой разрядностью мантиссы в Haskell (Hugs).

Наверное, можно. На том же приципе, что и арифметику больших целых чисел.
Для этого нужно просто создать собственный тип - экземпляр классов RealFloat (или Floating ?), Show, Read...
Правда, тут возникает вопрос - зачем? Разве что для тренировки?..

Мне как-то в одной довольно старой книге попалось утверждение о том, что больше 12-13 разрядов калькуляторы не могут считать по причине тепловых шумов в электронных схемах (или что-то типа того, короче, какой-то термодинамический предел...).
Хотя, наверное, это утверждение всё же ошибочно - современные сопроцессоры работают же с восьмидесятибитными числами - это что-то около 22-23 значащих цифр в мантиссе...

Ответ на »сообщение 1886« (Jack Of Shadows)
___________________________
С чего вы взяли ?
А как ещё обеспечить неизменяемость?

После некоторых размышлений начал понимать в чем "фикус-пикус" :)))
И вопрос могу сформулировать более конкретно. С целыми числами Hugs работает независимо от разрядности (реализует арифметику "больших" чисел). А вот с плавающей точкой получается предел ~15 значащих разрядов для Double. Можно ли реализовать арифметику чисел с большой разрядностью мантиссы в Haskell (Hugs).

Что интересно, если просто вывести очень большое число, например, 123123123123000000000.666, то все порядке: выводит значение в форме me+n с мантиссой и порядком.

Обнаружил одну странную вещь при работе с числами с плавающей точкой в Hugs. Вычисляется приближенное значение числа Фибоначчи с помощью метода простой рекурсии. На небольших значениях точность почти 100%. С увеличением номера числа n накапливается ошибка усечения, что понятно. А на значении n=38 результат удивительным образом "замерзает" на "магическом" числе 94906265.6242515 и больше уже не меняется!
module Fi where
main = do
  n<-readLn
  print (f n)
f n = 1/sqrt(abs(x*x+x-1)) where
  x = a n
  a 0 = 0
  a n = 1/(1+a(n-1))
То, что Double имеет ограничение по числу значащих цифр, это и ежику понятно. Но почему дальше 8 цифр в целой части дело не идет? 94 миллиона с "копейками" - это разве число для плавающей точки двойной точности?
Кто может объяснить и подсказать, как в Haskell грамотно работать с ЧПТ большого размера. Или, может это недоработка именно Hugs.

Ответ на »сообщение 1885« (hugi)
___________________________
Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично, что даёт существенное падение производительности. ;)
С каких это пряников?
"Не читайте советских газет!"(с)филиппфилиппыч

Ответ на »сообщение 1885« (hugi)
___________________________
Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично,
С чего вы взяли ?

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

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

Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично, что даёт существенное падение производительности. ;)

Еще интересной особенностью чистых ФЯ для оптимизации является их свойство referential transparency.
Из за того что все данные в чистых ФЯ immutable то есть неизменяющиеся, только для чтения, то создавая новую структуру из старой, не нужно старую копировать. Достаточно только дать ссылку на нее.
То есть в чистых ФЯ в отличии от ИЯ передача параметров по значению в пределах одного процесса отсутствует. Только по сслыке. Что дает очень большой выигрыш в производительности, поскольку копировать данные при передаче их в функцуии нет нужды. Передаются только указатели.

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

>>> А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).

А чего так много, если там только голые вычисления?

Честно говоря, не знаю. При расчёте 100-тыс эл-та списка программа захватила 7 мегабайт ОЗУ...


>>> Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).

Чего-то я не понял. Оно вычислялось в символьном виде, что ли?

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

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


А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).


А чего так много, если там только голые вычисления?


Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).

Чего-то я не понял. Оно вычислялось в символьном виде, что ли?

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

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

Вообще-то это вопрос не столько к языку, сколько к его транслятору.

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

Анализ строгости - задача, конечно, непростая, и очень важная (в плане быстродействия) для ленивых ФЯ. Если результаты каких-то вычислений рано или поздно придётся куда-то вывести, то вычислять их всё равно придётся, и там, где это возможно, транслятор должен делать энергичный код, при этом не переусердствовав.


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

Это вопрос к создателям используемого Вами транслятора.
По идее, анализ строгости может подсказать транслятору хранить в памяти только нужные вычисленные элементы списка (если предыдущие элементы нигде не используются).
В данном случае HUGS и GHCi, похоже, удерживают в памяти весь список, потому что очень сильно расходуют память. В этих интерпретаторах не производится анализ строгости, да и вообще какие-либо оптимизации, похоже.

А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).
Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).

У меня вопрос к знатокам ФЯ.
Ленивые вычисления и ленивые (бесконечные) структуры данных помогают повысить эффективность программирования в ряде ситуаций. Но насколько ленивыми являются эти конструкции?
Поясню суть моего вопроса на "классическом" примере.
Последовательность Фибоначчи можно определить в форме бесконечного (ленивого) списка следующим образом:
f = 1:1:[(a+b)|(a,b)<-zip f (tail f)]
Ленивость в данном случае заключается в том, что бесконечный список не создается до тех пор, пока мне не потребовалось реальное вычисление.
Но что будет происходить, если мне потребовалось значение, например, числа Фибоначчи с номером 100 - создание списка длиной в 100 чисел или только вычисление 100 элемента в данном списке?
print (f!!100)
В данном случае мне нужно только значение одного единственного целого числа. Будет ли программа реально строить список длиной 100 и занимать под него необходимую память или "поймет", что требуется только одно число из списка и для этого достаточно только "имитировать" построение списка в памяти -т.е. можно вычислять элементы в одной "ячейке" и не тратить на это больше памяти, чем требуется на самом деле?
Понятно, что вопрос имеет общий характер - как поступает ленивый ФЯ в подобных ситуациях?

Ответ на »сообщение 1877« (AVC)
___________________________
А вот в этой ветке
http://www.rsdn.ru/Forum/Message.aspx?mid=2184412#2184412
обсуждалось письмо "Как я утратил веру в Лисп":
http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6?hl=en&rnum=1/Quote]
Там в обсуждении очень дельные мысли одним из участников высказаны. По поводу субъективности оценок, данных Гатом самим свойствам языка, предметки Гугла (и вопроса об эффективности применения тех средств, которые используются гуглятами) и состояянию (и отношению к) языков программирования в федеральных конторах САСШ вообще и в НАСе в частности.
Такша... бабушка, как всегда, на двое сказала...

http://langexplr.blogspot.com/2007/02/list-comprehensions-across-languages_18.html
Интересная статейка приводящая список языков в которых есть list comprehension с примерами кода естесно.
Оказывается кроме haskell и Python уже куча просто языков поддерживает list comprehensions, включая новые сишарп и VB (ну там это называется Linq)
Хорошие идеи приживаются и становятся стандартом.

А вот в этой ветке
http://www.rsdn.ru/Forum/Message.aspx?mid=2184412#2184412
обсуждалось письмо "Как я утратил веру в Лисп":
http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6?hl=en&rnum=1

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

Сходная тема обсуждалась на rsdn.ru:

http://www.rsdn.ru/Forum/Message.aspx?mid=2126642#2126642

Ответ на »сообщение 1874« (Geniepro)
___________________________
А вы хоть эти документы читали ? :))
Вот вступление к одному из них:

Design patterns are reusable abstractions in object-oriented software.
However, using current mainstream programming languages,
these elements can only be expressed extra-linguistically: as prose,
pictures, and prototypes. We believe that this is not inherent in
the patterns themselves, but evidence of a lack of expressivity in
the languages of today. We expect that, in the languages of the
future, the code parts of design patterns will be expressible as
reusable library components.

И дальше идет доказательство на практике путем написание библиотеки, реализующей патерны на ФЯ.
То есть реализующей в виде библиотек а не трепа на тему "как правильно надо"

Далее, design patterns не что иное как попытка решить задачу инструментом, в котором механизмы абстракции не позволяют эту задачу формализовать.
Я никогда не говорил что в ФП вообще нет потолка абстракции. Есть конечно. Но он гораздо выше.
Вы можете всю свою жизнь работать на ФЯ и никогда не столкнуться с ТИПИЧНОЙ задачей, которую невозможно было бы реализовать в виде библиотеки. Это не значит что таких задач нет.
А вот в ООП - сплошь и рядом :))

Ответ на »сообщение 1873« (Jack Of Shadows)
___________________________
Ну вапще-то какие-то свои design patterns вроде есть и в ФП:

"Functional Logic Design Patterns". Sergio Antoy, Michael Hanus

"Design Patterns as Higher-Order Datatype-Generic Programs". Jeremy Gibbons

"TypeCase: A Design Pattern for Type-Indexed Functions". Bruno C. d.S. Oliveira and Jeremy Gibbons

Ответ на »сообщение 948« (Jack Of Shadows)
___________________________
По просьбам трудящихся, даю ссылку на давно утонувшее обсуждение design patterns.
Костыля, совершенно необходимого для ООП, и бесполезного в ФП.
От этого сообщения и дальше, пока поток сознания не перейдет на что то еще :))

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

ЗЫ. Есть ли версия емакса под Windows с GUI-интерфейсом? Под Линукс-то у меня есть, а вот под Windows - только переделанный под Mozart-Oz с GUI, а отдельный emacs (сам по себе) - с текстовым (консольным) интерфейсом...

Что-то я того...
У меня же есть, оказывается, GUI-версия Emacs 21.3 под Windows из пакета LispBox 0.7 c CLisp 2.37...
Как же так я о ней забыл??? 8-o

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

Поставил только что вышедший update haskell-mode для emacs
Типы показывает.

Любопытно, конечно. Я, правда, всё никак не могу овладеть этим редактором - непривычный у него дизайн...

Там что плохо в этом haskell-mode для emacs - то, что он не выводит типы сам, как я понял...
А это-то самое главное - типы стандартных функций и так запомнить можно, а вот проверка типа функции по мере её написания/редактирования (без перекомпиляции - как в F#) - вот это сильная вещь... Жаль, что Visual Haskell глючен ещё...


Так что emacs рулит :))

Не сомневаюсь! ;о)

Кстати, а плагины для емакса можно делать только на Лиспе? Вот интересно, можно ли встроить в haskell-mode модуль для type inference? Тогда это было бы действительно круто!

ЗЫ. Есть ли версия емакса под Windows с GUI-интерфейсом? Под Линукс-то у меня есть, а вот под Windows - только переделанный под Mozart-Oz с GUI, а отдельный emacs (сам по себе) - с текстовым (консольным) интерфейсом...

ЗЗЫ. Эх, разбаловали меня GUI-программы, консольные не переношу уже... :о))
Всё же скачал, начну щас снова пробовать сладить с емаксом...

Geniepro:
Поставил только что вышедший update haskell-mode для emacs
Типы показывает. Ctrl-C Ctrl-T
Причем если просто стать курсором на имя функции к которой один раз тип запрашивали, он уже показывает автоматически.
Типы функций из импортнутых модулей показывает автоматом.
Так что emacs рулит :))

http://thesz.livejournal.com/452186.html


Автоматическое распараллеливание программ.
Результаты поиска.

Достаточно простое описание.

Вкратце: распознаются разного рода шаблоны, наподобие трижды вложенного цикла с суммой умножений, который распознаётся, как умножение матриц (с заданными параметрами). Затем это дело преобразуется в параллельный код.

Как агрессивная оптимизация может быть использована замена алгоритма (!) вычислений, это в статье описано.

Ответ на »сообщение 1867« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1866« ()
___________________________
Где-то в первой трети "спектра" по "быстродействию"...
Меня по быстродействию даже лисп с питоном устраивают.
Ну так и меня устраивает. А мне сейчас это и не важно вобще.
Я не про разницу в языках говорил, а про один язык - хаскель.

Ответ на »сообщение 1866« ()
___________________________
Где-то в первой трети "спектра" по "быстродействию"...
Меня по быстродействию даже лисп с питоном устраивают.
А уж они то раз в 10 медленнее хаскеля.
Так что я особенно не заморачиваюсь.
Главное в хаскеле для меня ясность и короткость записи, то есть мое быстродействие.

Ответ на »сообщение 1864« (Jack Of Shadows)
___________________________
Кстати самая короткая запись в таком случае будет
xOR = /=
Попробовал. Где-то в первой трети "спектра" по "быстродействию"...
Хотя, канешна, в краткости, йомкости и обобщённости не откажеш.
Карринг есть очень вкусная пища для ума. Но нужно ещё очень долго это переваривать после стольких лет ереси императивщины...
В процессе изучения ФП вообще и Хаскелля в частности появляется смктно оформленная мысль на счёт существования "серебрянной пули". Теперь только нужны стрелки. :о)

В блогосфере разгорается весьма интересная дискуссия по поводу вреда (или пользы, зависит от точки зрения) операторов цикла в языках программирования.
http://syntaxfree.wordpress.com/2007/02/09/for-whom-the-bell-tolls/
Там найдете ссылки на остальные выступления.

Как водится, функциональщики ругают циклы, а императивщики рекурсию :))
Интересные аргументы в ту и в другую сторону.
Я на стороне рекурсии и map / fold конечно :)

Ответ на »сообщение 1863« ()
___________________________
А зачем вы передаете xOR tuple ?
Попробуйте декларировать
xOR x y = ...

Кстати самая короткая запись в таком случае будет
xOR = /=

:))

Да и еще, если поменяете в номере 4 Варианты местами то в тесте xOR ( False, False )
номер 4 может выйти на первое место, правда в каком то другом случае при этом может уступить :))
Последовательность в pattern matching имеет значение.

Делаю тут упражнения из одной книжки по Хаскеллю.
Вдруг вздумалось посмотреть для разных реализаций XOR количество редукций и ячеек...
Результат несколько удивил... :о)  Честно говоря, думалось, что результат будет противоположный полученному... (См. в конце)

---------------------------------------------------
xOR :: ( Bool , Bool ) -> Bool
---------------------------------------------------
1) xOR ( x , y ) = ( x || y ) && not ( x && y )

2) xOR ( x , y ) = not ( x == y )

3) xOR ( x , y ) = ( x && not y ) || ( not x && y )

4) xOR ( True , True  ) =  False
  xOR ( True , False ) =  True
  xOR ( False, False ) =  False
  xOR ( False, True  ) =  True

5) xOR ( x , y ) =
    case ( x    , y    ) of
          ( True  , True  ) -> False
          ( True  , False ) -> True
          ( False , False ) -> False
          ( False , True  ) -> True

6) xOR ( x , y ) = if x then not y else y

7) xOR ( True  , y ) = not y
  xOR ( False , y ) = y

8) xOR ( x , y ) | x == True  = not y
                | x == False = y

9) xOR ( x , y ) = x /= y
---------------------------------------------------

---------------------------------------------------
xOR ( True, True )
--------------------------
4) 27 reductions, 50 cells
6) 28 reductions, 50 cells
7) 28 reductions, 50 cells
5) 28 reductions, 52 cells
3) 29 reductions, 52 cells
8) 30 reductions, 53 cells
2) 31 reductions, 56 cells
1) 32 reductions, 58 cells
9) 36 reductions, 64 cells

xOR ( True, False )
--------------------------
4) 26 reductions, 46 cells
6) 27 reductions, 46 cells
7) 27 reductions, 46 cells
3) 27 reductions, 47 cells
5) 27 reductions, 48 cells
1) 28 reductions, 48 cells
2) 29 reductions, 49 cells
8) 29 reductions, 49 cells
9) 31 reductions, 51 cells

xOR ( False, False )
--------------------------
1) 27 reductions, 50 cells
4) 27 reductions, 50 cells
6) 27 reductions, 50 cells
7) 27 reductions, 50 cells
3) 28 reductions, 51 cells
5) 28 reductions, 52 cells
2) 30 reductions, 53 cells
8) 31 reductions, 56 cells
9) 32 reductions, 55 cells

xOR ( False, True )
--------------------------
4) 26 reductions, 46 cells
6) 26 reductions, 46 cells
7) 26 reductions, 46 cells
3) 27 reductions, 47 cells
5) 27 reductions, 48 cells
1) 28 reductions, 48 cells
2) 29 reductions, 49 cells
8) 30 reductions, 52 cells
9) 31 reductions, 51 cells
---------------------------------------------------

Самый быстрый
--------------------------------
4) xOR ( True, True  ) =  False
  xOR ( True, False  ) =  True
  xOR ( False, False ) =  False
  xOR ( False, True  ) =  True

Самый медленный
--------------------------------
9) xOR ( x , y ) = x /= y

Ответ на »сообщение 1858« (Jean)
___________________________
Кстати если вам нужно делать более сложный парсинг нежели числа разделенные запятыми, то есть прекрасная библиотека Parsec http://www.cs.uu.nl/~daan/download/parsec/parsec.html как раз для этой цели.
Документация там хорошая, с примерами.

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

А в GHC же есть библиотеки, которые реализуют Template Haskell...
Конечно, этим шаблонам далеко до макросов Лиспа, но вот вроде ребята из Немерле взяли их за основу своих макросов... Хотя там много праобразов макросов в Немерле - и Лисп, и Meta-ML...

Лисповые макросы не дают хаскелистам покоя :))
Вот один хаскелист написал лисп на хаскеле:
http://clemens.endorphin.org/liskell
Назвал гибрид как и полагается liskell.
Почему гибрид ? Потому что этот лисп генерирует хаскель код, который затем скармливается GHC компилятору.
То есть при помощи него можно генерировать хаскель код и потом им пользоваться в своих библиотеках.
Сделано это с одной единственной целью, получить доступ к макросам, поскольку все остальное что есть в лиспе есть и в хаскеле.

Ответ на »сообщение 1858« (Jean)
___________________________
Пусть будет последовательность целых числе, разделенных запятой.
Например "23,45,67"

safetail [] = []
safetail (_:x) = x   

splitList _ [] = []
splitList f x = (takeWhile (not . f) x) : splitList f (safetail (dropWhile (not . f) x))

Все. После этого передаете вашу строчку с числами вот этой функции:

map (\x -> read x::Int) (splitList (==',') "23,45,67")

Если числа разделены другим символом скажем вот так: "23;45;67" то передаете функции splitString этот символ вместо запятой:

map (\x -> read x::Int) (splitList (==';') "23;45;67")

Если нужно не целые числа считывать а скажем Float то

map (\x -> read x::Float) (splitList (==';') "23.2;45.34;67.12")

>>>Строчки в хаскеле являются списками, так что все функции работы со
>>>списками в вашем распоряжении.
ОК, спасибо. Но главный вопрос остался. Если у меня есть строка-список, которая содержит последовательность чисел, разделенных чем-то. То какой у меня имеется наиболее грамотный и простой способ сделать парсинг этой строки - получить список всех чисел из данной строки? Есть готовые механизмы в стандартных библиотеках типа Prelude и IO? Или надо самому писать парсер?

Ответ на »сообщение 1855« (Jean)
___________________________
А как числа в файле хранятся ?
Через запятую ? tab delimited ?

Делается легко

import qualified Data.ByteString.Lazy as B
import qualified Data.ByteString.Base as Base
import Char

main = do fromHandle <- openFile "d:\\test.txt" ReadMode
          contents  <- B.hGetContents fromHandle

Где contents будет одна длинная строчка которую можно обрабатывать по буковке в рекурсивной функции.
Строчки в хаскеле являются списками, так что все функции работы со списками в вашем распоряжении.

Ответ на »сообщение 1855« (Jean)
___________________________
вот это читали?
http://en.wikibooks.org/wiki/Haskell/YAHT/Io/Solutions#A_File_Reading_Program

2 All
Если не трудно помогите еще с одним вопросом.
Как в Haskell-программе ввести последовательность чисел из файла ASCII в список? Задача тривиальная, но нигде в сети не могу найти простой пример на эту тему.

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

Может кто поможет с одним вопросом.
Я всегда считал, что транслятор-интерпретатор читает последовательно конструкции исходного текста и тут же их исполняет. Но в функциональном программировании нет такого императивного понятия, как последовательное исполнение. Как в таком случае следует понимать слова "Haskell interpreter" в системе Hugs-98?


Лет эдак 5 назад в comp.lang.lisp (если не ошибаюсь) я встречал несколько другое определение интерпретатора:

Интерпретатор --- это функция f(Prog, Input) -> Output.

ИМХО, оно отвечает на Ваш вопрос.

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

Что интересно, автор статьи не противопоставляет Лисп и Хаскелл...

Интересно он их сравнивает: Лисп позволяет получать немедленную реакцию от компьютера во время написания программы, а Хаскелл заставляет чётко формулировать решаемую проблему и знания о ней...