И еще вы пишете «Зачем нужно прибавить единицу — не спрашивайте, результат эмпирический и без него получается криво». Возможно (хотя я внимательно не считал), это потому, что вы добавляете границу шириной в один пиксель перед работой алгоритма.
Я думаю, важно будет заметить, что алгоритм, используемый в статье, может делать ошибки в определении расстояний до ближайших черных пикселей. Его ошибки оцениваются вот в этой статье (Table II, колонка SWEDT). Причина для ошибок, насколько я понимаю, в том, что в доказательстве у авторов статьи [2] в вашем списке есть ошибка: в разделе 4 (доказательство) они предполагают, что ближайший черный пиксель для соседа будет таким же, как у текущего пикселя. Что, очевидно, не так.
Я бы никогда на это, наверное, не стал обращать внимания, если б у меня не было нескольких коллег с неплохими фотоаппаратами и объективами и, что важно, с хорошей теоретической базой (дорогие фотоаппараты с огромными объективами много у кого есть), и я бы не видел их фотографии.
Я думаю, это потому, что в самом начале статьи написано «Реакции окружающих долго ждать не пришлось. Практически сразу несколько человек обратили свой взор на смартфон и с насмешкой намекнули мне, что я лох жертва рекламы и маркетинга. В принципе в интернете можно наблюдать ту же самую картину.»
То есть статья позиционируется как попытка доказать, что 41Мп—это не маркетинговая уловка. И, как, опять же, справедливо заметил TDz, с этим не справляется (на мой взгляд, даже после добавления двух сравнений).
Обычно, насколько я знаю, под маркетинговым трюком понимается как раз то, что помимо мегапикселей есть другие параметры: фокусное расстояние, эффективное фокусное расстояние, абсолютный размер матрицы, светосила и т.п., которые влияют на качество фото—притом зачастую намного сильнее, чем мегапиксели.
Если вы хотите показать, что 41Мп—не маркетинговый трюк, вам нужно показать, что качество фото с вашего телефона сравнимо с качеством фото хороших или хотя бы средних фотоаппаратов, у которых все остальные параметры не так плохи, как у телефона.
«такие решения полностью определяются неподвижными точками оператора сдвига по траекториям системы». А расскажите, пожалуйста, что такое оператор сдвига в этом контексте и почему его неподвижные точки определяют периодические решения. И нельзя ли тогда, собственно, вывести этот оператор из системы (1), выбрать произвольное начальное C, найти решение x(t) для этого С и применять этот оператор, пока мы не сойдемся к его неподвижной точке (т.е. периодической траектории)?
В общем, вы правы. Тут только надо различать несколько сторон «идеальности»: наличие диссипации энергии (трение, неупругие столкновения) и «неидеальность» направлений (по сути—наличие тепловых флуктуаций, которые слегка искажают углы при столкновениях). Про отсутствие трения было явно сказано, про флуктуации—нет. Конечно, если все углы супер-идеальны, то как минимум два шарика будут бесконечно долго двигаться (вдоль вертикальных линий, если не столкнутся с другими—но даже при столкновениях траектории могут остаться периодическими). Но самое незначительное искажение траектории (физической природой которого может быть смещение хотя бы одного атома в шарике при столкновении) испортит идеальную картину.
Обычно в физике, насколько я знаю, предполагается, что такая «идеальность» намного «жестче», чем простое отсутствие диссипации энергии, и ее нельзя добиться. И действительно, избежать значимых потерь энергии на довольно большом промежутке времени вполне можно (т. е., чтоб ни один шар не остановился, пока не закатится), а вот флуктуаций избежать тяжело. В квантовых системах это вообще точные утверждения: потери можно сделать строго равными нулю (сверхпроводимость, сверхтекучесть), а флуктуации не исчезают даже при абсолютном нуле температур.
Математически говорят, что система неустойчива (в смысле Ляпунова).
В этих рассуждениях есть довольно тонкий момент: исходы есть, их множество бесконечное (но счетное), а вероятность их получить все равно равна нулю. Это называется множество меры нуль (в смысле теории меры, не путать с нульмерным множеством; хотя рациональные числа нульмерны тоже). Почему множество счетное, написано вот тут, а почему оно намного меньше множества действительных чисел, и почему намного легче получить иррациональное число, вот тут и тут (но довольно скупо).
А если у поверхности нет трения, то идеальная партия будет состоять из одного—самого первого—удара, потому что шарики будут кататься бесконечно. Более того, все они рано или поздно закатятся в лузы. Дело в том, что если траектория шарика не периодическая, он рано или поздно столкнется с любой точкой стенки, а значит, и с какой-то лузой. Некоторые периодические траектории тоже столкнутся с лузой (а некоторые—нет). Можно показать, что периодические траектории бывают только когда тангенс угла движения шарика (отн. горизонтальной или вертикальной оси) рационален. Но рациональных чисел намного меньше, чем иррациональных (точнее, мощность иррациональных чисел больше мощности рациональных, рациональные—счетные, иррациональные—несчетные), так что рациональные тангенсы почти никогда не будут получены. Хотя было бы интересно проверить численно или аналитически.
О какой высокой нагрузке можно говорить, если в книге sharepoint as a development platform есть раздел «Highly efficient data access», где рассказывается, как с помощью рефлексии .NET хакнуть sql базу шарепоинта (найти маппинг сущностей шарепоинта на сущности базы), чтоб делать запросы к листам руками. До такой степени он медленный и неэффективный. Да это же просто за гранью фантастики.
Я простооставлюнесколькоссылок, где люди обсуждают requests per second (с точки зрения cpu and memory bounds) в разных условиях.
10 запросов в секунду—это мизер даже для одного веб-сервера с минимальной конфигурацией. Для шарепоинта, может, это большое достижение, но это потому что он, в моем представлении—огромная машина с ужасной архитектурой. Точно так же asp.net намного медленнее asp.net mvc—потому что для отображения той же странички asp.net обрабатывает page life cycle, все события, viewstate, session state, бла-бла-бла, т.е. по пятнадцать раз проходит по дереву контролов вверх и вниз. Если сильно напрячься, то по меркам asp.net можно сделать очень быстрый сайт, но он все равно будет медленным. Выше головы, конечно, не прыгнуть, но это не повод говорить, что 10 запросов в секунду—это очень много.
Ну тут-то как раз их легко понять. Даже в несложных инженерных проектах, когда начинают использовать совсем новую технологию, обычно сначала «poke around», «щупают», делают пробный маленький проект, чтоб походить по всем граблям, понять ограничения, неизвестные факторы в работе с технологией и т.п. Вот и они так рассчитывали—«к 2012 году будут тысячи тестовых полетов». А их нет, потому риски непонятны, факторы непонятны, зрелость технологий, требования к безопасности непонятны и т.п., а решение принимать надо (а цена ошибки очень большая).
Ну и лично я (тоже) считаю, что валидация--это всегда валидация данных, и логически принадлежит business logic layer (domain model/services), и должна там находится. UI (View) и/или контроллеры, презентеры, ViewModel должны только вызывать/подключать методы валидации из domain services. Проблема только в том, что эти методы не должны возвращать строки, особенно если строки локализуются.
Совсем идеологически правильный вариант, на мой взгляд, это: 1. Сделать domain validation services (типа CustomerValidationService, OrderValidationService). Методы domain validation services возвращают объект со статусом валидации, кодом ошибки (если надо) и параметрами ошибки (словарь или список) (можно вообще на каждую ошибку сделать свой класс, но это уже оверкилл, по-моему) 2. Если у вас выделены в отдельный подслой presentation services, то пишутся соответствующие presentation validation services, в которые инжектируются domain validation services, и которые собирают коды ошибки во внятные предложения и локализуют, при необходимости. Они возвращают статус и сообщение ошибки, если надо.
При желании можно объединить эти сервисы и сделать так, что методы domain validation services, так и быть, сразу возвращают статус проверки и локализованное сообщение об ошибке.
Ну и дальше можно навешать плюшек: чтоб у каждого сервиса XxxValidationService был метод типа «CombinedValidationStatus DoAllValidations(T item)», выделить базовый класс, который бы имплементил этот метод через рефлексию и атрибуты и все такое. CombinedValidationStatus хранит статус проверки и все сообщения об ошибках, что нашлись. Можно добавить статус проверки типа warning и т.п.
А подключить валидации можно и через FluentInterface, хотя это уже не так важно, по-моему.
Я думаю, что FluentValidation--это валидация с использованием FluentInterface, и она может быть валидацией чего угодно (данных или форм). У вас в статье, получается, fluent validation форм, следуя вашему разделению.
По-моему, они совершенно взаимозаменяемы, при этом формализм Гамильтона выводится обычно из Лагранжева. Википедия, например, пишет, что
«Гамильтониан получается при выполнении преобразований Лежандра над функцией Лагранжа» (если мне не изменяет память, это преобразование обычно обратимое). Или, например, что «Legendre transformation is commonly used in thermodynamics and to derive the Hamiltonian formalism of classical mechanics out of the Lagrangian formulation.» В ней же есть раздел «Вывод [уравнений Гамильтона] из лагранжевой механики».
Я отвечал скорее на пункт «ну формулы и формулы»--это не просто формулы, это одни из самых важных формул, что знает человек (без преувеличения). Уже этого, я считаю, достаточно.
Но можно и сказать, как это относится непосредственно к компьютерам. Относится так, что это первый (из нескольких возможных) шаг к пониманию квантовых вычислений. А квантовые вычисления--это хорошо (модно, стильно, молодежно). Ну и в конце концов, на хабре не только непосредственно компьютерные статьи--скорее статьи, которые могут иметь интерес для ИТ-специалистов (про воздухоплавание, например). Кроме того, математическое моделирование многих задач (не только непосредственно физических; не говоря уже о непосредсвенно физических) начинается именно с Лагранжиана или Гамильтониана. Вот вам пример из теории оптимального управления: en.wikipedia.org/wiki/Pontryagin%27s_minimum_principle
1. малая светосила (большие шумы при съемке ночью/в сумерках/кадров с сильной неравномерностью освещения)
2. цветопередача (цвета совсем не такие яркие и сочные, как от нормальных фотоаппаратов)
3. бесконечная _неизменяемая_ ГРИП. Раньше меня это устраивало, но теперь все-таки нет—очень полезно иногда что-то убирать из фокуса
3. невозможность регулировать диафрагму/экспозицию.
И все это есть на фото автора—унылейшие цвета, куча шума в сумерках, унылая бесконечная ГРИП.
То есть статья позиционируется как попытка доказать, что 41Мп—это не маркетинговая уловка. И, как, опять же, справедливо заметил TDz, с этим не справляется (на мой взгляд, даже после добавления двух сравнений).
Если вы хотите показать, что 41Мп—не маркетинговый трюк, вам нужно показать, что качество фото с вашего телефона сравнимо с качеством фото хороших или хотя бы средних фотоаппаратов, у которых все остальные параметры не так плохи, как у телефона.
В общем-то, именно об этом написал TDz.
Я сам не большой специалист в фотографии, но есть хорошая серия статей как раз на эту и смежные темы.
Обычно в физике, насколько я знаю, предполагается, что такая «идеальность» намного «жестче», чем простое отсутствие диссипации энергии, и ее нельзя добиться. И действительно, избежать значимых потерь энергии на довольно большом промежутке времени вполне можно (т. е., чтоб ни один шар не остановился, пока не закатится), а вот флуктуаций избежать тяжело. В квантовых системах это вообще точные утверждения: потери можно сделать строго равными нулю (сверхпроводимость, сверхтекучесть), а флуктуации не исчезают даже при абсолютном нуле температур.
Математически говорят, что система неустойчива (в смысле Ляпунова).
10 запросов в секунду—это мизер даже для одного веб-сервера с минимальной конфигурацией. Для шарепоинта, может, это большое достижение, но это потому что он, в моем представлении—огромная машина с ужасной архитектурой. Точно так же asp.net намного медленнее asp.net mvc—потому что для отображения той же странички asp.net обрабатывает page life cycle, все события, viewstate, session state, бла-бла-бла, т.е. по пятнадцать раз проходит по дереву контролов вверх и вниз. Если сильно напрячься, то по меркам asp.net можно сделать очень быстрый сайт, но он все равно будет медленным. Выше головы, конечно, не прыгнуть, но это не повод говорить, что 10 запросов в секунду—это очень много.
наказывать ли компанию в случае катастрофы, произошедшей из-за того, что пассажир нарушит требования безопасности
в чьей юрисдикции находятся летательные аппараты
кто ответственен, если пассажиру стало плохо, потому что тесты здоровья проходили задолго до полета
как работать страховым компаниям с этими полетами
могут ли запуски оставлять космический мусор (и если да, то какие его допустимые пределы на полет; как его мониторить, как штрафовать за нарушения)
и т.п.
Совсем идеологически правильный вариант, на мой взгляд, это: 1. Сделать domain validation services (типа CustomerValidationService, OrderValidationService). Методы domain validation services возвращают объект со статусом валидации, кодом ошибки (если надо) и параметрами ошибки (словарь или список) (можно вообще на каждую ошибку сделать свой класс, но это уже оверкилл, по-моему) 2. Если у вас выделены в отдельный подслой presentation services, то пишутся соответствующие presentation validation services, в которые инжектируются domain validation services, и которые собирают коды ошибки во внятные предложения и локализуют, при необходимости. Они возвращают статус и сообщение ошибки, если надо.
При желании можно объединить эти сервисы и сделать так, что методы domain validation services, так и быть, сразу возвращают статус проверки и локализованное сообщение об ошибке.
Ну и дальше можно навешать плюшек: чтоб у каждого сервиса XxxValidationService был метод типа «CombinedValidationStatus DoAllValidations(T item)», выделить базовый класс, который бы имплементил этот метод через рефлексию и атрибуты и все такое. CombinedValidationStatus хранит статус проверки и все сообщения об ошибках, что нашлись. Можно добавить статус проверки типа warning и т.п.
А подключить валидации можно и через FluentInterface, хотя это уже не так важно, по-моему.
«Гамильтониан получается при выполнении преобразований Лежандра над функцией Лагранжа» (если мне не изменяет память, это преобразование обычно обратимое). Или, например, что «Legendre transformation is commonly used in thermodynamics and to derive the Hamiltonian formalism of classical mechanics out of the Lagrangian formulation.» В ней же есть раздел «Вывод [уравнений Гамильтона] из лагранжевой механики».
Но можно и сказать, как это относится непосредственно к компьютерам. Относится так, что это первый (из нескольких возможных) шаг к пониманию квантовых вычислений. А квантовые вычисления--это хорошо (модно, стильно, молодежно). Ну и в конце концов, на хабре не только непосредственно компьютерные статьи--скорее статьи, которые могут иметь интерес для ИТ-специалистов (про воздухоплавание, например). Кроме того, математическое моделирование многих задач (не только непосредственно физических; не говоря уже о непосредсвенно физических) начинается именно с Лагранжиана или Гамильтониана. Вот вам пример из теории оптимального управления: en.wikipedia.org/wiki/Pontryagin%27s_minimum_principle