- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
double fact(int value)
{
switch (value)
{
case 0:
return 1;
break;
case 1:
return 1;
break;
default:
return value * fact(value - 1);
break;
}
}
Конечно, case 0 и case 1 можно было бы объедениться в единый блок.
В остальном всё верно.
отлично сочетается с рекурсивным вычислением факториала
гамма функция рулит
http://www.boost.org/doc/libs/1_41_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_gamma/tgamma.html
http://bit.ly/HTmdFi
жду реализации заполнения массивов компайл-тайм на Аде и факториала до 100 члена в частности
Delphi 7 Proffesional Peerat Edition?
Govno.NET
Не используется LINQ.
Просто поциенты считают, что Linq - панацея от всего. В том числе от отсутствия головного мозга.
И пихают оный где нужно и где не нужно.
Циклы, например - не нужны. Есть where и лямбды.
Треды не нужны - есть asParallel. Алгоритмы - не нужны, есть Linq. Мозг не нужен - пусть за меня думает Microsoft.
>ЛИНКВ удобная тема.
Правильно. А факториалы нужно считать рекурсивно через switch.
Ведь умный конпелятор сам сделает из кейсов конфетку.
То есть паттерн Стратегия с динамическим связыванием и вызовом разных функций с идентичными сигнатурами, однозначно красивей, чем императивный оператор switch?
А функция-предикат однозначно красивей, чем императивный if?
>Мне нравится стиль ЛИНКВА.
И сахар в виде extension-методов тебе тоже нравится, когда вызывается как бы метод объекта, а на самом деле это какой-то левый статический метод.
Это тоже красиво?!
http://www.gamedev.ru/flame/forum/?id=147021&page=7
Или надо написать тривиальный case (оператор множественного выбора).
Нормальный человек пишет case.
Поциент, больной оопиозом головного мозга, напишет по одному классу на каждую ветку этого case, а сам case заменит на вызов виртуального метода.
Для каждого case - свой набор классов.
Кол-во классов у такого поциента может быть астрономическим, код сам по себе пухнет из-за тормозных абстракций на ровном месте.
Для полноты слива мне осталось только добавить "я всё это учудил для того, чтобы потроллить".
На самом деле я сторонник KISS. Но .where и .foreach таки красивее чем цикл.
А .AsParallel ВАЩЕ ОХУЕННО!!!
еще недавно был настоящим байтоебом
В 90% кода приложений, с которыми я работаю, разница в производительности цикла и функции высшего порядка не имеет значения (вызов веб-сервиса порой занимает пару секунд, какой смысл экономить на спичках?), и я скорее отдам предпочтение функциям высшего порядка.
Функции высшего порядка не отменяют необходимости анализа алгоритмов, и уж сложности они точно не прибавляют (немного меняют константы, но не порядок).
Преподносить LINQ как какую-то уникальную технологию - смешно, ведь все идеи, лежащие в его основе, известны уже десятки лет (всё это довольно детально описано в SICP). Но и ничего плохого в нём я не вижу.
Именно.
>и я скорее отдам предпочтение функциям высшего порядка.
Но это совсем не повод совать функциональщину где попало. Даже в тех местах где обычный цикл короче и эффективней.
И не нужно забывать про оверхед (в жабе вовсе чудовищен, но и в более продвинутом шарпе его хватает), когда для написания кастомной логики нужно создавать дополнительные объекты типа делегатов, extension-методов и других вспомогательных сущностей.
Тут, безусловно, такой подход легитимен. Собственно для увеличения энтропии кода он и создан.
Но и злоупотреблять не стоит, ибо функциональный код иногда читается хуже, чем императивный.
С этим я и не спорю. Хотя компактность, как правило, повышается. Здесь, как обычно, на помощь приходит чувство меры.
И про меру тоже правильно сказано.
Короче, новомодная функциональщина как и когда-то ооп, полезны не всегда.
Как я уже говорил выше: считать linq серебрянной пулей - нельзя.
Да и вообще зря они в изначально сбалансированный структурно ооп-шный язык вносят спорные улучшения.
Как по мне, то шарп теряет свою стройность, которая была в версии 2.0 и потихоньку превращается в эзотерику подобную С++, где напихано всего и помногу.
Адептам пейсать всё на linq порекомендовал бы пересесть на какой-то функциональный язычок, где императивно кодить попросту нельзя.
Но мне больше по нраву православный Nemerle.
2)Нет проверки аргуентов (уже назвали).
4)Нужно объединить кейсы 1 и 0 (уже назвали).
5)Лучшеб не выпендривался и написал не рекурсивный алгоритм.
6)Добавил бы мемоизацию аля массив.