Подробнее
Я напишу рекурсивную функцию И тыукажешь базовый случай? И ты,укажешь базовый случай? Я напишу рекурсивную функцию Я ивлишу рекурсивную, функцию
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Энакин и Падме на пикнике,it-юмор
Еще на тему
![■
л
Pi %
\
ч
л
г
» %
г V
!•
ИДЯ изучаю CSS •*](http://img2.joyreactor.cc/pics/thumbnail/post-4857871.jpg "■
л
Pi %
\
ч
л
г
» %
г V
!•
ИДЯ изучаю CSS •*")
Рано или поздно оно само остановится. Или по стеку, или по памяти.
Может ещё по ограничителю глубины рекурсии выпасть, но это наш путь.
Вопрос, ловится ли переполнение стека в try...catch, предлагаю не поднимать.
хуже уже не будет
опять считать уже посчитанное - не оптимально
предлагаю или мемоизировать результаты предыдущей рекурсии
или распараллеливать текущую
как - хрен знает, не ко мне вопрос, я не джун, я тимлид, я думаю стратегически
дальше только два выхода - в консоль или в глобальный catch
{
try {
neverGiveYouUp()
} catch (ANYException e) {
neverGiveYouUp()
} finally {
System.out.println("Life is strange");
neverGiveYouUp()
}
}
public neverGonnaGiveYouUp() {
try {
neverGonnaLetYouDown();
} catch (ANYException e) {
neverGonnaRunAroundAndDesertYou();
} finally {
neverGonnaGiveYouUp();
}
}
А с вычислением того-же числа Пи рекурсивной функцией это странный пример. Начиная с того что проще взять значение нужной точности со спец.сайта, а не расходовать впустую мощность, вычисляя самому. И заканчивая тем что глубина рекурсии в этом случае может быть разной, и меняться от запуска к запуску. Или вообще, например как в Java, зависеть от версии или даже ключа запуска. Уж если возникло странное желание повычислять Пи то уж разложи рекурсию в цикл и вычисляй с НУЖНОЙ точностью.
А закольцованные данные это как?
Чёто мы с юмор и сарказма в серьёзное дерьмо переехали
Вычисление числа Пи было взято в качестве абстрактного примера. Допустим это не константа, а некоторое значение, которое необязательно должно быть совершенно точным, но желательно рассчитать его поточнее и за ограниченное количество времени, а рекурсивный метод сочтён аналитиками оптимальным с точки зрения соотношения затрат к точности. В этом случае не важно, что результат будет иметь разную точность при разных запусках, важно что это лучшее что мы можем выдать за приемлемое время.
Закольцованные данные это, например, когда ты рекурсивно обходишь деревообразную структуру, где потомок может быть предком самого себя.
А аналитики странные, рекурсия вроде бы в любом современном языке по умолчанию тяжелее цикла (если компилятор сам не разложил её в цикл), за счёт как раз накладных расходов на стек и прочее. Допускаю что бывают задачи когда точность не сильно важна, но вот не могу представить такую где было бы нормально считать до упора, а сколько там получится по итогу - не сильно важно. Железо всё таки дешёвое но не бесконечное, особенно если надо ответить на сетевой запрос который висит, ждёт ответа и занимает целый сокет. Особенно если можно не вычислять вовсе, а подсунуть готовое значение.
Имхо рекурсия в коде это больше для удобства программиста, потому что этот самый код проще и очевиднее.
Да, наверняка в большинстве случаев рекурсия дороже цикла и по памяти и по сложности, но есть ещё один важный фактор: стоимость переписывания рекурсии на цикл. Я никогда не видел, чтобы кто-то ловил StackOwerflowException в рекурсивном алгоритме, но я был свидетелем ловли OutOfMemoryException с последующим разбиванием "слишком большого для обработки" дерева на части в catch-секции. Это было грубым, но дешёвым решением, в смысле затрат человеко/часов. При этом понятно, что возникло оно когда стало ясно, что OutOfMemoryException возникают на практике, а не когда мы проектировали алгоритм в целом.
тащемто мы тут в юмор пытались, а ты сюда на серьёзных щщах влетаешь
точка, в которой значение функции равно её аргументу называется fixed point.
функция, которая принимает функцию и возращает её fixed point называется fixed point combinator. У любой функции есть fixed point (теорема, в лямбда исчислении доказана)
по определению:
f x0 = x0, Y f = x0
подставляем второе в первое:
f (Y f) = Y f
подставляем правую часть в левую:
f (f (Y f)) = Y f
подставляем правую часть в левую:
f (f (f (Y f))) = Y f
подставляем правую часть в левую:
f (f (f (f (Y f)))) = Y f
подставляем правую часть в левую:
f (f (f (f (f (Y f))))) = Y f
подставляем правую часть в левую:
f (f (f (f (f (f (Y f)))))) = Y f
короче я думаю принцип понятен
Што? В данной формулировке утверждение неверно. Например, когда область определения и область значений функции не пересекаются. И даже если пересекаются: f(x) = x + 1.
как я выше написал, я сам не понимаю как оно так получается. подозреваю, что ф-ии лямбда исчисления это не те ф-ии которые в матанализе например, по этому для ф-ий из матана это не верно, но это не точно. отвечаю поздно, потому что был в бане.
И вовсе не "у любой функции". А у любого терма из лямбда-исчисления, это совсем не значит "у любой функции".