| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1892 20-02-2007 14:14 |   |
Ответ на »сообщение 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 значащих цифр в мантиссе...
| № 1891 20-02-2007 12:51 | |
Ответ на »сообщение 1886« (Jack Of Shadows)
___________________________
С чего вы взяли ?
А как ещё обеспечить неизменяемость?
| № 1890 20-02-2007 04:16 | |
После некоторых размышлений начал понимать в чем "фикус-пикус" :)))
И вопрос могу сформулировать более конкретно. С целыми числами Hugs работает независимо от разрядности (реализует арифметику "больших" чисел). А вот с плавающей точкой получается предел ~15 значащих разрядов для Double. Можно ли реализовать арифметику чисел с большой разрядностью мантиссы в Haskell (Hugs).
| № 1889 20-02-2007 03:44 | |
Что интересно, если просто вывести очень большое число, например, 123123123123000000000.666, то все порядке: выводит значение в форме me+n с мантиссой и порядком.
| № 1888 20-02-2007 02:32 | |
Обнаружил одну странную вещь при работе с числами с плавающей точкой в 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.
| № 1887 20-02-2007 01:38 | |
Ответ на »сообщение 1885« (hugi)
___________________________
Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично, что даёт существенное падение производительности. ;)
С каких это пряников?
"Не читайте советских газет!"(с)филиппфилиппыч Сообщение не подписано
| № 1886 19-02-2007 14:50 | |
Ответ на »сообщение 1885« (hugi)
___________________________
Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично,
С чего вы взяли ?
| № 1885 19-02-2007 14:01 | |
Ответ на »сообщение 1884« (Jack Of Shadows)
___________________________
Что дает очень большой выигрыш в производительности, поскольку копировать данные при передаче их в функцуии нет нужды. Передаются только указатели.
Но каждая (почти) операция над этими данными приводит к копированию их целиком или частично, что даёт существенное падение производительности. ;)
| № 1884 19-02-2007 11:27 | |
Еще интересной особенностью чистых ФЯ для оптимизации является их свойство referential transparency.
Из за того что все данные в чистых ФЯ immutable то есть неизменяющиеся, только для чтения, то создавая новую структуру из старой, не нужно старую копировать. Достаточно только дать ссылку на нее.
То есть в чистых ФЯ в отличии от ИЯ передача параметров по значению в пределах одного процесса отсутствует. Только по сслыке. Что дает очень большой выигрыш в производительности, поскольку копировать данные при передаче их в функцуии нет нужды. Передаются только указатели.
| № 1883 19-02-2007 10:31 | |
Ответ на »сообщение 1882« (pepper)
___________________________
>>> А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).
А чего так много, если там только голые вычисления?
Честно говоря, не знаю. При расчёте 100-тыс эл-та списка программа захватила 7 мегабайт ОЗУ...
>>> Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).
Чего-то я не понял. Оно вычислялось в символьном виде, что ли?
Ну, может быть я и загнул, и размер всего этого списка был не сто гигов, а пятьдесят (если числа хранятся там в двоично-десятичном виде - в одном байте по две цифры).
Но всё равно намного больше, чем объём виртуальной памяти на моём компе...
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
