какие языки самые поездатые-2

ormorph написал:

Просто я привел вариант алгоритма, который довольно сильно загружает процессор.

Ваш пример загружает процессор бесполезной работой. Которой нет на C. Вот и всё, что я хотел сказать - код на С отлично ложится на современное железо, а лисп - не ложится. Потому-то лисп и работает на порядок медленнее.

ormorph написал:

Такой вариант будет выполняться мгновенно.

да. Но вы отказались от списков и "красоты". А это вроде самое главное в LISP'е. На С и такой подход работает, и рекуррентный, как в лиспе.

ormorph написал:

В sbcl вызов (fibonacci 10000) считает мгновенно, ну и число получается приличное, если нужна точность вот оно:

ничего не стОит реализовать длинную арифметику и на С. Только нужно такое сто лет в обед.

ormorph написал:

В каждом языке свои преимущества для решения определенных задач

ну с этого я и начал собственно smile

drBatty написал:

Ваш пример загружает процессор бесполезной работой. Которой нет на C. Вот и всё, что я хотел сказать - код на С отлично ложится на современное железо, а лисп - не ложится. Потому-то лисп и работает на порядок медленнее.

Доктор почему? На СИ этот код так же загружает процессор, просто вызовы интерпретируемого языка на много сложнее, от сюда и потеря производительности.

Например можно попробовать переписать ваш вариант кода на тип int64_t и сравнить с переписанным последним примером с lisp на си

и попробовать подсчитать обоими 50 число Фибоначи.
1)

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
int64_t fib(int64_t x)
{
    return x < 2 ? x : fib(x-1) + fib(x-2);
}
int64_t main()
{
    int64_t x;
    int64_t r = scanf("%"PRId64, &x);
    if(r <= 0)
        return 70;
    printf("%"PRId64, fib(x)); printf("\n");
    return 0;
}

2)

#include <stdio.h>
#include <stdlib.h>
#include <inttypes.h>
int64_t fib_iter (int64_t a, int64_t b, int64_t count){
  if (count==0) return b;
  return fib_iter((a+b), a, (count-1));
}
int64_t fib(int64_t x)
{
  return fib_iter(1, 0, x);
}
int64_t main()
{
    int64_t x;
    int64_t r = scanf("%"PRId64, &x);
    if(r <= 0)
        return 70;
    printf("%"PRId64, fib(x)); printf("\n");
    return 0;
}

60 -е число даже не предлагаю считать, 1-й пример это делать будет очень долго oO

ormorph написал:

Доктор почему? На СИ этот код так же загружает процессор, просто вызовы интерпретируемого языка на много сложнее, от сюда и потеря производительности.

не только в этом всё дело. Хотя и это тоже.
Но не это главное.

ormorph написал:

text

int64_t fib_iter (int64_t a, int64_t b, int64_t count){ 
 if (count==0) return b; 
 return fib_iter((a+b), a, (count-1)); 
}

функционально программирование съёло ваш мозг. :(
отловите любого школьника, и попросите решить эту задачу. Он её решит без всякого стека
0
1
0+1=1
1+1=2
1+2=3
2+3=5
и так далее.
Как видите, на каждую итерацию нужно всего два слова. Вы зачем-то используете N слов. Точнее, вы используете N+N*M слов. Здесь M это длинна результата в словах (в предположении, что она растёт линейно, это не совсем так, но для простоты расчётов это допустимо).
Т.е. для каждой итерации у вас в стеке сохраняется не только адрес возврата, но ещё и прошлый с позапрошлым результатов. Как вы уже поняли, результаты тут имеют совсем не маленький объём. И самый простой, процедурный подход требует только двух переменных для данных. Ну а функциональный - N переменных.

Для N == 10000 у вас получилось число в 2090 цифр
это

26455354C816C43235B9A5B9708A80EC209E5A36521B054E1F08B364AC5F9EA8A618\
BA6203D6598679F82A57B25E5727326C1BEC42026ED6BB5E577D20563519B1086FA7\
8E79A13DF45829FA84BFD0AB6F0B2DBEB34CDD8BE556F2BA12DC96342BC50CD1C313\
479C2C83AFDFDD28C1F9FCFF8EE23EEEE443349BA0964E0AA29F35941217D12487CE\
CACDC9CCC9B77D11D14F72BCCC265FD0FE7F831747EBE7634B9A246915F996315C79\
DE01E48EFA8A52CAAE6BE757783411BE20664AB19D18CC63AF13E623895D5C879D5F\
3B1D5768317FBF95DC91FBF8402131015E5F5154F3B14DCFDA6C3E88BABEE1BA1173\
94C9EE4360096BDF6650209D8005BCC5E2459072F8066895C7331F271051F2830EDD\
CC8A0102DF15711544823B820D863EC63AB8ED88A777D4C7CFED7563DAB155C06D05\
7C0BACB621E2D50B7A655E647EA443C8555005BB5D7066096A2E811D53571E24181D\
FE37FF0979AF3B063B133BDC511FE7FC3E71C74D2529F1E6C218F213EECF09A09194\
857B1130A3E8DFD9CF3B38E6A18A68103C4698D3E014DC8D6D59EC1C6D2478BD16E4\
2A20FBCB81B03C86470AFE986FE20AD2C54706CD01D198BCC78BF5A0B0C6FA15C258\
5647635F965925246AF87C8D05CC0F072355F3D31867944AEF1C0AD65B32DA8121EB\
BC36AC1A3554BEE17AB8E680DB4C6F305AE9836CA2B8BEEB64D2B1BD5F6B801139AE\
B8298BF53AE4EEA0B4237965F95C6CBC92F5BE3427CBD0B2E8771C54B578032F865C\
D74E66CB093D51B51F808308B71FCAFE88250528A3F5D1E308A1A9CE9872547FA5AC\
C2CF434B9503B368066143606EA5458B0B9ED1538A465EAA4638A340B8AB274AAAC0\
60A56F2D2FA639B7A8CBF00ADAD2286AB2B299C9ADF471647736E8B97B5A6F8781CF\
0707617BE5570BB649C47E122F6D4781BF97BC02BFBDF59D558820DF190348081A30\
28FA2F3EFBF486D2F69AEB5C8FB963F27BF01300F047E4989C9CAD353A1EE19AA207\
52F5789EA65AAEFC62DD5F836456C17B08B5194C682118570AEBDFECD446A1F63AE2\
61A299C23C6AB19E7B2758E4FE91D35D8FE1D5DFF7359FB73A5DEDB172765B205628\
AC2DCF0DE6865874CCC0CB5369623FB3E96F09A07D07F4753F50034CCACE3542ED83\
D69BBD346E43A1D4BF5C229A116B35F9F98E4C8752CA26035035F30F7DB929B9C06F\
A898222219DEE5079FAAD824476D4A0819DB

1736 тетрад
или 217 слов на x86_32
Т.е. при N=10000, вам потребуется примерно 2 180 000 слов. А мне всего 434. Как говорится - почувствуйте разницу. :P

На самом деле, функциональное программирование работает только на простых, тестовых примерах - даже в нашем тривиальном случае вам пришлось найти почти 9 мегабайт. И это в Си! Не сомневаюсь, что ваша программа на lisp'пе пожрёт не 9, а 99 метров. И это тогда, когда простой тупой подход требует жалких двух килобайт.

Вы всё ещё пишете на функциональных ЯП? :lol:

Доктор, если присмотреться, то второй пример как раз и представляет собой итерационный метод решения, просто там применен функциональный подход, вместо простого оператора цикла, которые например в comon lisp тоже присутствуют. :P
В лиспе, можно тоже оттрасировать функцию, и просмотреть это все. Это функции trace untrace

ormorph написал:

Доктор, если присмотреться, то второй пример как раз и представляет собой итерационный метод решения, просто там применен функциональный подход

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

ormorph написал:

вместо простого оператора цикла, которые например в comon lisp тоже присутствуют.

я знаю что присутствует. Только лисперы им уже не пользуются - мосгЪ уже съеден... :(

ЗЫЖ функциональный подход заставляет вас ВСЁ хранить в списках. Это на самом деле плохо, ибо список - это не идеальная структура данных. Точнее - очень редко когда она идеальная. Конечно, математикам куда как проще оперировать списками для доказательства исчислимости, и для решения своих очень важных задач. Но то - математикам. А я практик. Для математика вполне нормально, что теорема доказана, и функция выполнима. Всякие мелочи, вроде N*M чисел на стеки его абсолютно не интересует - работает же! А мелочи потом программисты исправят, в конце концов, это их работа... В принципе правильно конечно, вот только исправлять их куда как лучше на других ЯП, никак не на этих лямбдах.

На прошлой странице уже была тут как пример qsort(), дык мало того, что она в таком рафинированном виде никогда не применяется, но это мелочь - часто она вообще в принципе НЕ применима. Например внутри GNU Linux ядра. Ну а если начать её окастыливать, то мы увидим, что как раз таки в лиспе у нас это и не получится. А вот в C - легко.

Хм что то я не нашел на прошлой странице qsort() там было только quickSort, но это не Lisp, это был haskell, тоже использует лямбда нотацию, но это уже строго типизированный язык.

ormorph написал:

Хм что то я не нашел на прошлой странице qsort() там было только quickSort, но это не Lisp, это был haskell, тоже использует лямбда нотацию, но это уже строго типизированный язык.

а quicksort это не тоже самое, что qsort()?
а то я хтого вашего хаскеля не разумею...

drBatty написал:

а то я хтого вашего хаскеля не разумею...

Ну и правильно там все равно приведен не рабочий вариант(возможно намерено)
Вот по идее рабочий вариант, у меня на ghc-7.0.4 собралось:

import System.IO
quickSort [] = []
quickSort (h : t) = quickSort [n | n <- t, n <= h] ++ [h] ++ quickSort [n | n <- t, n > h]
main = print . quickSort =<< getLine

Остается только скомпилировать ghc filename.hs -o file, а дальше выполняешь и вводишь с клавиатуры всякую белеберду, а она все упорядочивает smile

Вообщем тут эта функция не встроенная, она объявляется.
Сам в хаскеле не очень, все нет времени заняться изучением, но исправить вроде хватило ума wink

Для меня последняя строчка странная. "Соглашения об именовании" - эт что? Классов, методов, переменных?

И еще. Эта картинка - про то что питон хороший язык или наоборот?

unk написал:

И еще. Эта картинка - про то что питон хороший язык или наоборот?

:lol: наоборот

Ну вот, только я собрался заказать книжек по Питону... smile

unk написал:

1. Для меня последняя строчка странная. "Соглашения об именовании" - эт что? Классов, методов, переменных?
2. И еще. Эта картинка - про то что питон хороший язык или наоборот?

1. всего :(
2. плохой.

-=Serj=- написал:

Ну вот, только я собрался заказать книжек по Питону...

Кнута закажите.

-=Serj=- написал:

Ну вот, только я собрался заказать книжек по Питону... smile

Заказывай, он самый поездатый.
Но опять же, согласен с высказываниями о том, что каждый язык хорош по-своему

drBatty написал:

Кнута закажите.

Боюсь я его не осилю даже с пол-литрой... :(

-=Serj=- написал:

Боюсь я его не осилю даже с пол-литрой..

зря. На самом деле там нет ничего сложного. Ну можете первое время математику пропускать.

-=Serj=-, осилите питон, C++ для вас будет как семечки smile
На самом деле Python очень удобен и читабелен своей реализацией. Всё остальное зависит от состояния
обрастаемости разработчика wink

drBatty написал:

зря. На самом деле там нет ничего сложного. Ну можете первое время математику пропускать.

Уговорили. Раздобыл 3 тома в DJVU. Попробую полистать, но как мне показалось математика - это 85% материала.
Хотя нет - только 25. :D

Wolfenberg написал:

осилите питон, C++ для вас будет как семечки

Я тоже так думаю. smile В свое время не осилил С++, т.к. не въехал в ООП... Нет, студенческие задачки я решал, но Программировать на нем так и не пошло.
На Питоне, думаю проще добиться конкретных результатов, а дальше можно будет усложниться (если не надоест smile )

-=Serj=- написал:

Раздобыл 3 тома в DJVU. Попробую полистать, но как мне показалось математика - это 85% материала.

чисто ради интереса, что составляют остальные 15?