Да просто АйБиЭмовский PR, к тому же многие ли станут вникать в детали реализации подобной модели? Численная математика интересна небольшому проценту читателей, в то время как новости из мира численной математики — значительно большему.
Публикации по этой работе еще нет, но я подозреваю, что они использовали те же методы, что вот в этой статье. То есть particle-based approach и level sets.
Это не я. Это авторы статьи. Вообще, в computer vision часто называют вещи терминами из физики. Видимо, люди которые работают по этой теме пришли из этой области. Можете попробовать, кстати, другие варианты подсчета энергии и посмотреть что получится.
Да, я знаю. В этом случае надо помечать более важные пискели в ручную. Либо, если есть информация о глубине — например с Kinect — то можно усложнить функцию придавая более близким объектам большую энергию, нежели более удаленным.
Загружает процессор сильно, так как использовано динамическое программирование. Было бы интересно вместо него использовать какой-то вероятностный алгоритм поиска локального минимума, который бы работал при этом намного быстрее.
Я не знаю как ее отформатировать. На мой взгляд код не верно парсился. Потому что верстка страницы такая же как в codeproject — там работает, здесь нет. Я пару часов убил на разбирание с тем как движок хабра парсит это несчастье и сдался. Если у вас есть желание помочь — я могу вам прислать и потом запостить отформатированный код. Напишу во вступлении «спасибо за помощь в редактировании статьи такому-то». А ну и я патологический не грамотен в плане русского
Я честное слово не вижу рассказа с позиции рефакторинга. Т.е. я под этим подразумеваю a-la «вот был такой-то код, он решал такую-то задачу. Теперь мы захотели его исправить применив связку таких-то паттернов.»
Про статью я невнятно выразился. Пример статьи я привел не для того чтобы Вы писали про этот конкретный паттерн. А к тому, что есть паттерны которые не так широко афишированы как GoF'ские, но могут быть интересны широкой аудитории. А о паттернах GoF написано настолько много статей, что сложно добиться новизны при написании собственной статьи. Кроме, быть может, подбора интересных примеров использования. Этого я как раз не вижу — только toy samples.
Резюмируя критику — недостаточный список литературы, отсутствие новизны как по содержанию, так и по способу подачи материала.
Хотя это не значит, что я считаю вашу статью не полезной — у нас в сообществе до сих пор паттерны это что-то сложное и космическое. Образовывать массы надо. Но массы пишут больше про особенности реализации, чем про ООД, что и печалит и наводит на мысли.
В целом — мне непонятно, в чем ваша статья отличается от других аналогичных статей, которых тьма на том же codeproject. Про фабрики и С++ — есть книжка Александреску, на которую вы не сослались. Там и про полиморфные и про абстрактные фабрики. Про порождающие паттерны в целом лучше всего написано в книгде Refactoring to patterns. Ее я то же не вижу в списке литературы.
Примеры ваши — toy samples. Они не показательны. Я понимаю, что доступные real life примеры сложно придумать — но в том-то и сложность написания статей по тематике.
Есть еще менее известный паттерн Trader [1], о котором на русском нет статей.
Ну и имхо — лучше с позиции рефакторинга паттерны рассматривать. Мне хочется верить, что это не преумножает pattern-happy программистов.
[1] Product Trader, by Baumer & Riehle in Pattern Languages of Program Design 3, Eds Martin, Riehle, Buschman, 1998, pp 29-46.
К верификации в целом есть некоторые вопросы. Много обнадеживающих научных статей на эту тему, но в индустрии видно мало выхлопа (почему — то же интересно). В основном, в проектах вроде ПО для спутников, военных и так далее. Интересны перспективы этого направления CS в широкой индустриальной разработке.
ps пример с auto_ptr в chrome — методологичнее советовать использовать unique_ptr нежели boost::scoped_ptr.
а то так и не узнают люди про с++0х. все еще бетту студии (09 год) используют, мда.
Скажите как или ссылку дайте. Я ожидаю что когда я код обрамляю тегом <code /> код будет подсвечен как на codeproject. Но нет — так не произошло. Вместо это съехали пробелы, а в середине вообще кошмар.
PRISM и прочие — это хорошо. Но! Фреймворки не заменяют понимание паттерна. Мне хотелось сделать статью о MVVM начального уровня. Те без лишних деталей, которые отнюдь не упрощают понимание кода. Когда я сам разбирался с этим паттерном постоянно натыкался на overengineered toy примеры кода, в которых было всего до полна, но задачи не из реальной жизни.
Знал бы как. Я замучился с ним. Я писал вокруг каждого фрагмента кода тег и ожидал увидеть выделение кода a-la codepoject (там примерно так же обрамляется код тегом code). Но нет. Как сделать красивое форматирование кода здесь?
Про статью я невнятно выразился. Пример статьи я привел не для того чтобы Вы писали про этот конкретный паттерн. А к тому, что есть паттерны которые не так широко афишированы как GoF'ские, но могут быть интересны широкой аудитории. А о паттернах GoF написано настолько много статей, что сложно добиться новизны при написании собственной статьи. Кроме, быть может, подбора интересных примеров использования. Этого я как раз не вижу — только toy samples.
Резюмируя критику — недостаточный список литературы, отсутствие новизны как по содержанию, так и по способу подачи материала.
Хотя это не значит, что я считаю вашу статью не полезной — у нас в сообществе до сих пор паттерны это что-то сложное и космическое. Образовывать массы надо. Но массы пишут больше про особенности реализации, чем про ООД, что и печалит и наводит на мысли.
Примеры ваши — toy samples. Они не показательны. Я понимаю, что доступные real life примеры сложно придумать — но в том-то и сложность написания статей по тематике.
Есть еще менее известный паттерн Trader [1], о котором на русском нет статей.
Ну и имхо — лучше с позиции рефакторинга паттерны рассматривать. Мне хочется верить, что это не преумножает pattern-happy программистов.
[1] Product Trader, by Baumer & Riehle in Pattern Languages of Program Design 3, Eds Martin, Riehle, Buschman, 1998, pp 29-46.
ps пример с auto_ptr в chrome — методологичнее советовать использовать unique_ptr нежели boost::scoped_ptr.
а то так и не узнают люди про с++0х. все еще бетту студии (09 год) используют, мда.
std::for_each(mycontainer.begin(), mycontainer.end(), [this](val_type element) {...}):