Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
 
 11:24 Den Sarych
 
 
Во Флориде и в Королевстве сейчас  11:27[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

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

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 1922—1913 | 1912—1903 | 1902—1893 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 360


    № 1912   21-02-2007 11:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1911« (Geniepro)
    ___________________________


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


    Поставил -O2. Та же фигня. Компилятор скачивал вчера. Может там еще чего-то покрутить надо?


    № 1911   21-02-2007 10:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1910« (pepper)
    ___________________________

    Похоже на полный бред. Или ты путаешь калькуляторы с АЦП/ЦАП.

    За что купил, за то и продаю... :о))

    К сожалению, не могу найти ту книгу и не помню автора, но точно помню, что там так объяснялось, почему у обычных калькулаторов 8-9 разрядов, а у лучших (и дорогущих) - 12...
    Объяснялось это вроде довольно убедительно - в детстве, когда я читал эту книгу, она меня убедила. Сейчас сомневаюсь... :о))
    Книга была старая, а может быть автор её был в неадеквате, когда описывал эту теорию...


    Я не поленился и набросал такой простенький тестик:
    ...
    Программа съела больше гига памяти и ушла в своп. Компилировал GHC. Почему даже на таком простом примере компилятор не смог ничего соптимизировать (выкинуть конструирование очень большого списка)?

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

    Я обычно компилирую программы простеньким bat-файлом, в котором указана опция -O2 (или можно просто -O - качество кода, по утверждению создателей GHC, будет почти таким же).
    Так что этот код отработал у меня, потратив всего 2.5 мегабайта памяти и никаких свопингов...


    № 1910   21-02-2007 09:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1881« (Geniepro)
    ___________________________


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


    Я не поленился и набросал такой простенький тестик:


    test_list = 0 : test_list

    index xs 0 = head xs
    index xs n = index (tail xs) (n - 1)

    main = do
    print (index test_list 1000000000)



    Программа съела больше гига памяти и ушла в своп. Компилировал GHC. Почему даже на таком простом примере компилятор не смог ничего соптимизировать (выкинуть конструирование очень большого списка)?


    № 1909   21-02-2007 09:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1892« (Geniepro)
    ___________________________


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


    Похоже на полный бред. Или ты путаешь калькуляторы с АЦП/ЦАП.


    № 1908   21-02-2007 07:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1907« (Денис Зайцев)
    ___________________________
    Долго набивал :) Geniepro меня опередил.


    № 1907   21-02-2007 07:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1901« (Geniepro)
    ___________________________
    Функцию Вашего знакомого обдумать надо - почему у неё после n=37 происходит такая катастрофическая потеря точности. Но в любом случае, даже если реализовать плавающую арифметику с, например, миллионом цифр в мантиссе, быстрее простого целочисленного варианта точно не будет, и при этом опять же точные результаты будут даваться только до определённого значения n, а после него опять произойдёт резкий рост погрешности...
    Может быть аналитически эта функция и верна, но непрактична однозначно...

    Совершенно верно, эта функция непрактична. Потому что чрезвычайно чувствительна к ошибкам округления. Можно показать, что последовательность a(n) экспоненциально сходится к числу "золотого сечения" ~0.6180339... (это число является корнем уравнения x^2+x-1 = 0). А затем мы вычисляем a(n)^2+a(n)-1, в результате получается вычитание двух очень близких друг к другу (и к единице) чисел, что и ведёт к потере значащих цифр (катастрофической для больших n). Реально вычисленная последовательность a(n) начиная с некоторого номера N стабилизируется (при любом n>N a(n) = наиболее близкое к числу "золотого сечения", представимое в процессоре или языке). Поэтому неудивительно, что стабилизируется и f(n).

    Вот здесь можно почитать обсуждение вопроса о том, как быстрее всего считать n-й член последовательности Фибоначчи:
    http://algolist.manual.ru/maths/count_fast/fibonacci.php


    № 1906   21-02-2007 07:00 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1905« (Geniepro)
    ___________________________

    Основан на свойстве чисел Фибоначчи - соседние числа дают отношение, равное золотому сечению

    Пардон. Не равное, а приближающееся к золотому сечению отношение...


    № 1905   21-02-2007 06:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1900« (Jean)
    ___________________________

    Подсказал один знакомый математик :))). Кстати, к формуле он приложил ее строгий аналитический вывод на 2 листах :).

    Мда... Любопытный алгоритм. В принципе, похоже (интуитивно) - правильный.
    Основан на свойстве чисел Фибоначчи - соседние числа дают отношение, равное золотому сечению - ((sqrt 5 + 1) / 2) = 1.61803398874989...
    Чем больше номера чисел в ряду Фибоначчи, тем ближе это отношение к золотому сечению. И тем больше влияние погрешности плавающей арифметики в компьютере. Так что после определённого n эта разница становится такой маленькой, что не отличается от машинного эпсилона - вот и происходит сбой, функция выдаёт одно и тоже значение при любых n, больших критического...
    Аналитически формула верна, но практически неприемлема...


    № 1904   21-02-2007 01:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1898« (Jack Of Shadows)
    ___________________________
    А вот как прогнать список функций над одним значеним ?
    Казалось бы надо писать новый map который будет принимать 1 значение и список функций, который она будет вызывать с этим значением.

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

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

    Output: [8,12,9]

    Это не только красиво, это ещё и ближе к математической нотации, а значит - более правильно. Вместо 3 ставим объект, характеризующий положение в партии в шахматах, а список - список возможных сценариев стратегий дальнейшей игры... Всё наглядно.
    Сообщение не подписано


    № 1903   21-02-2007 00:52 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1898« (Jack Of Shadows)
    ___________________________

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

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

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

    Output: [8,12,9]

    Забавно.
    Но на самом деле тут всё же стандартное действие функции map - применение функции ($ 3) к списку (содержащем функции в данном случае) [(+5), (*4), (^2)].
    Вот что значит функции - объекты первого класса... ;о)


    <<<... | 1922—1913 | 1912—1903 | 1902—1893 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 360


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

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

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования