Matlab как питон — хорош для быстрого прототипирования, серьёзные расчёты считает неприемлемо долго.
Из своего опыта — в университете помогал с дипломом, задача из области теории потоков (математический аппарат пересекается с гидро- и термодинамикой).
Первая попытка — Matlab+Simulink, верная модель, преподаватель всё проверил и одобрил. Одна проблема — считает неприемлемо долго (на моём пк за сутки около 1%).
Вторая попытка — голый Matlab без Simulink, уже лучше, но всё равно долго.
Третья попытка — переписал весь код на C++, день-другой конечно с отладкой повозился и оптимизациями, получилось быстрее в несколько раз, но всё равно долго. Помогла аренда High-CPU instance на AWS — там всё просчиталось за ночь.
У меня было 48Mб памяти с видеокартой на 2Мб! и видеоускорителем с отдельными 2 Мб, что-то по типу Voodoo 3dfx кажется. Даже Motocross Madness работал.
Тоже смотрел этот терминал, там клавиатура такая же, как в МФЦ (правда, у нас в городе стоят немного другие терминалы, с трекболом) (см. пост), но сам терминал настроен значительно лучше. У меня получилось свернуть приложение чем-то вроде Ctrl+F4, но добиться чего-то большего, к сожалению, не удалось.
Я имел ввиду, что требование совместимости с Windows 7 и использование UWP — несовместимые требования. К XP это конечно же тоже относится, ничего не имею против.
Мало ли что там считает MS :)
Пока приложения UWP запускаются в песочнице — довольно большое количество софта не сможет перейти на эту платформу.
Плюс в нагрузку всё ещё существуют требования по совместимости с Windows 7 — большое количество обычных пользователей используют её и никуда не собираются уходить.
Хотя темпы развития WPF меня совершенно не радуют, для десктопа пока лучше ничего не видел.
Почему сразу даунгрейд. Это другая версия, использующая другой SDK. UWP имеет множество ограничений, и дальнейшее развитие на этой платформе, к сожалению, практически невозможно.
Если вы подскажете мне, как без танцев с бубном в UWP:
1. Подключить сборки .net framework
2. Упаковать, распространять и ставить вместе с приложением сервис Windows
3. Распаковывать и запускать произвольные бинарники
то наша команда изменит своё мнение.
Но из-за алгоритма отката традиционный NFA может проверять одно и то же место несколько раз, что отрицательно сказывается на скорости работы.
, так что одного суждения по времени работы будет недостаточно. А ещё рекурсивный поиск обычно не используется не столько из-за времени работы, сколько из-за потребляемой памяти, так что замерьте ещё потребление памяти, раз уж берётесь за такое. Если оно тоже быстро растёт — тогда я с вами соглашусь.
Рекомендую ещё посмотреть, что пишет Microsoft про реализацию регулярных выражений.
А именно:
The .NET Framework regular expression engine is a backtracking regular expression matcher that incorporates a traditional Nondeterministic Finite Automaton (NFA) engine such as that used by Perl, Python, Emacs, and Tcl. This distinguishes it from faster, but more limited, pure regular expression Deterministic Finite Automaton (DFA) engines such as those found in awk, egrep, or lex. This also distinguishes it from standardized, but slower, POSIX NFAs.
NFA (англ. nondeterministic finite-state automata — недетерминированные конечные автоматы) используют жадный алгоритм отката, проверяя все возможные расширения регулярного выражения в определённом порядке и выбирая первое подходящее значение. NFA может обрабатывать подвыражения и обратные ссылки. Но из-за алгоритма отката традиционный NFA может проверять одно и то же место несколько раз, что отрицательно сказывается на скорости работы. Поскольку традиционный NFA принимает первое найденное соответствие, он может и не найти самое длинное из вхождений (этого требует стандарт POSIX, и существуют модификации NFA выполняющие это требование — GNU sed). Именно такой механизм регулярных выражений используется, например, в Perl, Tcl и .NET.
Поправлю. Есть такой тип конечных автоматов — ДКА с магазинной памятью (ДМПА), которые позволяют разбирать даже контекстно-свободные грамматики. Думаю, с регулярками с обратными ссылками такие автоматы тоже могут справиться.
Рекурсивные алгоритмы разбора используются в качестве обучающих и для небольших объёмов данных, насколько мне известно, нормальные реализации всё-таки используют конечные автоматы.
Регулярки удобно использовать в основном для поиска/замены шаблонных конструкций, при этом желательно сохранять небольшой размер выражения, чтобы можно было потом разобраться. Мне как-то приходилось на .net регулярках делать разбор, например, валидного набора объявлений переменных с тем, чтобы регулярка падала ровно на месте первой синтаксической ошибки — вот это ад и израиль, никогда не делайте таких вещей в реальных проектах. Вот код если кому интересно
Из своего опыта — в университете помогал с дипломом, задача из области теории потоков (математический аппарат пересекается с гидро- и термодинамикой).
Первая попытка — Matlab+Simulink, верная модель, преподаватель всё проверил и одобрил. Одна проблема — считает неприемлемо долго (на моём пк за сутки около 1%).
Вторая попытка — голый Matlab без Simulink, уже лучше, но всё равно долго.
Третья попытка — переписал весь код на C++, день-другой конечно с отладкой повозился и оптимизациями, получилось быстрее в несколько раз, но всё равно долго. Помогла аренда High-CPU instance на AWS — там всё просчиталось за ночь.
Всегда к вашим услугам.
Я имел ввиду, что требование совместимости с Windows 7 и использование UWP — несовместимые требования. К XP это конечно же тоже относится, ничего не имею против.
Пока приложения UWP запускаются в песочнице — довольно большое количество софта не сможет перейти на эту платформу.
Плюс в нагрузку всё ещё существуют требования по совместимости с Windows 7 — большое количество обычных пользователей используют её и никуда не собираются уходить.
Хотя темпы развития WPF меня совершенно не радуют, для десктопа пока лучше ничего не видел.
Если вы подскажете мне, как без танцев с бубном в UWP:
1. Подключить сборки .net framework
2. Упаковать, распространять и ставить вместе с приложением сервис Windows
3. Распаковывать и запускать произвольные бинарники
то наша команда изменит своё мнение.
К сожалению, да. Сейчас по работе перевожу один проект с UWP на WPF (с кучей анимации тем и прочих плюшек), такая боль.
Хочу, правда, отметить, что , так что одного суждения по времени работы будет недостаточно. А ещё рекурсивный поиск обычно не используется не столько из-за времени работы, сколько из-за потребляемой памяти, так что замерьте ещё потребление памяти, раз уж берётесь за такое. Если оно тоже быстро растёт — тогда я с вами соглашусь.
Рекомендую ещё посмотреть, что пишет Microsoft про реализацию регулярных выражений.
А именно:
регулярных выражений.
Цитата:
Вот код если кому интересно