Вот что пишут про Lucene (ну а Lucene.NET--его порт): Since we love Open Source here at Twitter we chose Lucene, a search engine library written in Java, as a starting point. После этого вы будете сомневаться, брать ли его на реальный проект?!
Есть еще такой трюк, как расширенная вещественная прямая--когда добавляются к вещественным числам понятия плюс-бесконечность и минус-бесконечность. Тогда делить на ноль вполне можно (если известен знак, с которого стремятся к нулю). А вот в вещественных числах, действительно, нельзя. Но, опять же, предел в делении на ноль брать можно.
Я думаю, точно так же. Во-первых, обычно, когда говорят state machine, подразумевают finite, а во-вторых, исторически в русском не сложилось двух разных понятий для этих моделей.
Чтоб проверить, вы можете зайти на википедию, на статью state machine, и потом выбрать слева русскую версию статьи--вы окажетесь на статье «конечный автомат»)
Тут нужно не забывать, что это lossless алгоритм, в отличие от JPEG. То есть для алгоритмов с потерей действительно куча критериев: есть ли артефакты, какие пространственные гармоники они передают, насколько хорошо картинка выглядит для человека после сжатия и т.п.
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
Даже для основного языка, C#, студия без решарпера--очень неудобная, и заодно медленная (с решарпером тоже медленная, зато удобная). Навигация, автокомплит, поиск ошибок при наборе кода, не при компиляции, подсветка синтаксиса, сниппеты и т.п.--все хуже.
А про остальные языки лучше и не вспоминать: для javascript даже notepad++ лучше, чем студия: подсветка лучше, indent lines, подсвечиваются парные скобки (даже этого в студии нет!). А лучше всего WebStorm или функционал WebStorm в решарпере.
Для С++ студия тоже не годится. Мне необходимо было перейти с C# на C++, и я провел небольшое сравнение. Eclipse CDT на голову обходит студию: по автокомплиту, навигации по коду (через Ctrl+left click), подсветке, поиску ошибок на лету (при наборе кода, не при компиляции) и т.п. NetBeans, Code::Blocks тоже лучше (хотя мне меньше понравились, чем Eclipse).
«Как раз перевод в явную схему обычно сложностей не представляет.» Уверяю вас, вы очень сильно заблуждаетесь. Для простейших уравнений--не представляет. Для Навье-Стокса, Фоккера-Планка, Больцмана--представляет. Даже простое уравнение диффузии вы нормально не решите при сложных граничных условиях; поэтому приходится пользоваться вот этим методом: en.wikipedia.org/wiki/Single_particle_tracking.
«начинается турбулентность и неустойчивость самого течения» В том-то и фокус, что до турбулентности еще далеко, а схема начинает расходиться.
Я для примера привел) Как ни странно, как раз полгода назад я начал делать PhD по близкой теме, для продолжения работы своих коллег. Но они пользовались методом решеток Больцмана для моделирования гидродинамики в пористой среде, без всяких приближений типа закона Дарси.
Как пишут в комментарии ниже, скорее всего, вы что-то неправильно закодировали, потому что вы далеко не первый, кто решает подобные задачи. И ошибки должны появляться намного позже шестого знака после запятой (в бенчмарках типа потока Пуазейля, по крайней мере).
И как пишет небезызвестный Стив Макконнел в книжке «Совершенный код», если вы видите следы копыт, не думайте что это зебра (в смысле «ошибка компилятора/базы данных/реализации стандартов/и т.п.»).
Кстати, вот что вы для начала можете рассчитать: бенчмарки а ля поток Пуазейля, течение Куэтта, конвекция Рэлея-Бенара и т.п.
Насколько я понимаю, зависит еще и от того, как эта схема получена. Уравнения гидродинамики (Навье-Стокса) нелинейны сами по себе, и перевод их в явную конечно-разностную схему--нетривиальная задача. То есть неустойчивость появляется не на этапе решения схемы, а на этапе перехода к этой схеме.
Например, вычислительная схема метода решеток Больцмана полностью явная, но устойчивость сильно зависит от начальных условий.
Даже если моделировать простой поток Пуазейля (по трубе) со слишком большим градиентом давления--решение расходится.
Вот еще несколько идей:
4. некоторые алгоритмы требуют, чтобы результаты расчетов брались не на каждой итерации, а, например, через одну; или как полусумма значений на соседних итерациях; от этого могут быть ошибки
5. могут быть проблемы в параллелизме. Если программа хорошо спроектирована и вы можете заменить параллельную версию на непараллельную быстро (то есть заменить вызовы OpenMP вызовами методов-заглушек (через директиву прекомпиляции), которые ничего не делают), то попробуйте сделать так. Если нет, попробуйте дампить состояние системы на каждой итерации, и смотреть как оно меняется. Может быть, вы заметите что-то странное именно там, где присутствует распараллеливание. Либо менять число процессорных узлов.
Вот что еще может быть:
1. вы запускаете алгоритм вне допустимых значений параметров (например, для некоторых алгоритмов жидкость должна быть несжимаемой, то есть числа Маха очень маленькими, меньше 0,001, то есть предельная скорость жидкости маленькой; некоторые по тем же или другим причинам требуют малых чисел Рейнольдса/Рэлея/Нуссельта); поэтому решения расходятся.
2. если вы используете генератор случайных чисел (для фазовых превращений, например), то попробуйте использовать более медленный, но лучшего качества
3. решение может расходиться, если разностная схема низкого порядка (например, если считать якобианы/производные не по квадратичной схеме, а по линейной)
Вот в этом комментарии есть множество полезных способов дебага ошибок моделирования гидродинамики.
По-моему, это совсем не agile. Agile--это гибкая разработка (как следует уже из названия), и его основная идея--уменьшение времени обратной связи между всеми участниками: заказчик-мэнеджмент (или product owner), мэнеджмент-программисты (итерации и ретроспективы итераций), программисты-тестеры, мэнеджмент-ТЗ (если есть--в agile может и не быть) и всевозможные комбинации.
А у вас, скорее, правила эффективного кодинга с поправкой на agile.
Спасибо за статью! Насчет оформления, раз уж вы сами спрашиваете: лично мне больше нравится читать статьи, в которых между всеми абзацами текста присутствует пустая строка (это относится к тексту о минимальном соседнем пороге).
Тогда сразу проще использовать protobuf, мне кажется, или xml сериализацию. В бинарные файлы удобно записывать именно какой-нибудь огромный массив int, float, bool после, например, численных расчетов--только тогда это удобнее и быстрее.
Эта программка рассчитана на запуск на суперкомпьютерах, типа вот этого. Есть задачи, для которых и их мощностей не хватает, так что вариант с докупкой железа не сработает:-)
Выше поинтересовались насчет примера, где алгоритм в разы медленне на C#, чем на С++, вот я и привел пример (что касается бенчмарков, то я замерял уже на своей программе--замена виртуальных функций обычными в самых интенсивных циклах давала прирост 30% производительности--и это только виртуальные функции; а есть еще проверки доступа к границам массива, boxing/unboxing, garbage collection и тп).
Да и вообще, идея с докупкой железа работает только для веб-приложений. И, мне кажется, нам всем очень везет, что не все десктопные приложения написаны на яве и C# (вот утилитка Manic Time на .Net занимает 25Мб в трее).
Вот тут здоровый проект по моделированию гидродинамики, есть и ролики, и открытый исходный код (сама компания зарабатывает на консалтинге). Скачайте, не поленитесь--там С++, и там _вообще_ не используют виртуальные функции--только шаблонный полиморфизм, потому что виртуальные функции--это медленно. А вы говорите «Си шарп», «ява». Сборка мусора погубит производительность нахрен.
Мне кажется, это не сразу получится: busy beaver--это пример машины тьюринга; а регекспы описываются конечными автоматами, и уступают в мощности машинам тьюринга. Вот тут про это есть.
Чтоб проверить, вы можете зайти на википедию, на статью state machine, и потом выбрать слева русскую версию статьи--вы окажетесь на статье «конечный автомат»)
А для lossless алгоритмов основных критериев по сути всего три (не учитывая патенты): скорости распаковки, упаковки и степень сжатия (хотя она, конечно, может зависеть от типа изображения).
Так что пример со jpeg не совсем подходит сюда. Хотя патенты и аппаратную часть, конечно, интересно было бы сравнить.
Даже для основного языка, C#, студия без решарпера--очень неудобная, и заодно медленная (с решарпером тоже медленная, зато удобная). Навигация, автокомплит, поиск ошибок при наборе кода, не при компиляции, подсветка синтаксиса, сниппеты и т.п.--все хуже.
А про остальные языки лучше и не вспоминать: для javascript даже notepad++ лучше, чем студия: подсветка лучше, indent lines, подсвечиваются парные скобки (даже этого в студии нет!). А лучше всего WebStorm или функционал WebStorm в решарпере.
Для С++ студия тоже не годится. Мне необходимо было перейти с C# на C++, и я провел небольшое сравнение. Eclipse CDT на голову обходит студию: по автокомплиту, навигации по коду (через Ctrl+left click), подсветке, поиску ошибок на лету (при наборе кода, не при компиляции) и т.п. NetBeans, Code::Blocks тоже лучше (хотя мне меньше понравились, чем Eclipse).
«начинается турбулентность и неустойчивость самого течения» В том-то и фокус, что до турбулентности еще далеко, а схема начинает расходиться.
И как пишет небезызвестный Стив Макконнел в книжке «Совершенный код», если вы видите следы копыт, не думайте что это зебра (в смысле «ошибка компилятора/базы данных/реализации стандартов/и т.п.»).
Кстати, вот что вы для начала можете рассчитать: бенчмарки а ля поток Пуазейля, течение Куэтта, конвекция Рэлея-Бенара и т.п.
Например, вычислительная схема метода решеток Больцмана полностью явная, но устойчивость сильно зависит от начальных условий.
Даже если моделировать простой поток Пуазейля (по трубе) со слишком большим градиентом давления--решение расходится.
4. некоторые алгоритмы требуют, чтобы результаты расчетов брались не на каждой итерации, а, например, через одну; или как полусумма значений на соседних итерациях; от этого могут быть ошибки
5. могут быть проблемы в параллелизме. Если программа хорошо спроектирована и вы можете заменить параллельную версию на непараллельную быстро (то есть заменить вызовы OpenMP вызовами методов-заглушек (через директиву прекомпиляции), которые ничего не делают), то попробуйте сделать так. Если нет, попробуйте дампить состояние системы на каждой итерации, и смотреть как оно меняется. Может быть, вы заметите что-то странное именно там, где присутствует распараллеливание. Либо менять число процессорных узлов.
1. вы запускаете алгоритм вне допустимых значений параметров (например, для некоторых алгоритмов жидкость должна быть несжимаемой, то есть числа Маха очень маленькими, меньше 0,001, то есть предельная скорость жидкости маленькой; некоторые по тем же или другим причинам требуют малых чисел Рейнольдса/Рэлея/Нуссельта); поэтому решения расходятся.
2. если вы используете генератор случайных чисел (для фазовых превращений, например), то попробуйте использовать более медленный, но лучшего качества
3. решение может расходиться, если разностная схема низкого порядка (например, если считать якобианы/производные не по квадратичной схеме, а по линейной)
Вот в этом комментарии есть множество полезных способов дебага ошибок моделирования гидродинамики.
А у вас, скорее, правила эффективного кодинга с поправкой на agile.
Выше поинтересовались насчет примера, где алгоритм в разы медленне на C#, чем на С++, вот я и привел пример (что касается бенчмарков, то я замерял уже на своей программе--замена виртуальных функций обычными в самых интенсивных циклах давала прирост 30% производительности--и это только виртуальные функции; а есть еще проверки доступа к границам массива, boxing/unboxing, garbage collection и тп).
Да и вообще, идея с докупкой железа работает только для веб-приложений. И, мне кажется, нам всем очень везет, что не все десктопные приложения написаны на яве и C# (вот утилитка Manic Time на .Net занимает 25Мб в трее).
Спасибо за статью!