sergei-grigorev

У нас в институте компьютерную графику преподавал «бывший» сотрудник милиции. Он нам рассказывал, что вычислить изменения в фотографии не сложно, обычно достаточно просто пройтись гистограммой. В случае редактирования изображения, обычно в гистограмме должны быть хорошо заметные ошибки, т.к. полутона изображения, яркости пикселей, будут нарушены в этом случае.

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

Все зависит от задачки. Порою достаточно простого цикла, с ним и работать проще и нет проблем со стеком. Еще, лучше все таки в цикле решать задачи, где результат следующего полностью зависит от результата предыдущего (например, факториал).

При других задачках (например, обход вложенных каталогов), когда при этом у каждого имеется ряд своих отдельных переменных (например, количество файлов в данном каталоге), или асинхронных потоков, то поддерживать легче будет рекурсию. Да и рекурсия в данном случае будет удобнее, потому что обход одного каталога совсем не зависит от результатов обхода другого соседнего каталога, и они могут работать параллельно, независимо друг от друга. А затем в конце просто объединяют все свои результаты.

Еще рекурсия будет эффективна, если рекурсивная функция кешируемая, например, она запоминает результат и при следующем запросе просто возвращается кешированный вариант.

Читаю частенько, и если куда-то уезжаю, то беру книги с собой, чтобы почитать их в пути.