Как стать автором
Обновить
109
0
Василий Баранов @Bas1l

Пользователь

Отправить сообщение
Реполная статья--повод не удалять ее, а улучшать.
С таким никогда не сталкивался (и лучше бы вам обратиться к текущему разработчику ), но, может, это результат оптимизации компилятора, когда он просто не вызывает создание массивов, если нет других операций впоследствии?
Это полезная штука.

Есть стандартная структура статей: вступление, основная часть и заключение.

Вступление нужно для того, чтобы дать высокоуровненвый обзор; чтобы читатель знал, на что обращать внимание.

А заключение нужно для того, чтобы еще раз напомнить основную идею, чтобы у вас сложилась цельная картина.

Кроме того, повторение--мать учения. Кажется, чтобы информация запомнилась, ее надо повторять через 20 минут, через пару чаов и через пару дней. Заключение как раз и соответствует первому повторению.
Интересный подход.

Маленькое замечание: по-моему, в XmlResult надо передавать объект модели, а не строку, и строку формировать уже внутри--тогда код для сериализации можно будет убрать из контроллера. Это улучшит разбиение по слоям, система будет соответствовать Single Responsibility Principle, и views станут взаимозаменяемыми (можно будет легко заменить XmlResult на любой другой).

Если у вас сложная система моделирования гидродинамики или молекулярной динамики, которая потребляет 500Гб оперативной памяти (заполняя небольшие массивы), и расчет производит за 24 часа на суперкомпьютере, притом доступ к этим массивам происходит постоянно, то это весьма полезный код.
Теперь по крайней мере можно отвечать со статистикой на аргумент правообладателей о недополученной прибыли. Что, мол, наоборот, прибыль не недополучается, а переполучается)
Прекрасная статья!

Тем не менее, позволю себе напомнить, что погоня за эффективными и красивыми алгоритмами никогда не должна являться самоцелью, и ее необходимость всегда должна предварительно оцениваться.

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

Например, если нам подходит другая сторона компромисса память/время, то большинство этих примеров легко реализовать без treapa, просто вычисляя меру на подотрезках заново. Плюс код будет намного лучше, читабельнее, сопровождаемее.

И да, торт!
В Notepad++ есть похожая тема Zenburn--можете черпать вдохновение еще и оттуда)
Как один из вариантов: сначала читаете Троелсена, потом Рихтера, потом первые 110 страниц базового курса Эспозито, чтоб понять, как работает ASP.NET pipeline; а потом, например, Сандерсона--сам MVC.
Статья интересная и заставляет задуматься, но вот это: «Мы все заметили ясное и заметное улучшение продуктивности после отказа от овертайма. Продуктивность в смысле ценности для пользователя, производимой в единицу времени.»--просто супер-объективная статистика.
Верно. Для полноты картины добавлю, что есть еще QMake и PreMake. Лично мне очень понравился PreMake, потому что используется стандартный скриптовый язык Lua.
Имхо, нормальная теория вероятности даст фору по сложности всем четырем идеологиям, вместе взятым. Особенно если пытаться ее применять на практике (стохастическое моделирование, скрытые марковские модели, и тп). Хотя за год их, конечно, не выучить.
Это лучше стандартными методами гидродинамики обсчитывать. Уравнения Навье-Стокса, метод конечных элементов, и тп. Другой уровень абстракции, так сказать.
А вы не задумывались насчет GROMACS?

Кстати, по молекулярной динамике есть хорошая книжка Computer simulation of liquids (и <a href=«www.filestube.com/abb88c84ad44045503ea,g/Computer-Simulation-of-Liquids.html»бесплатно). Она 1989 года, но нам ее рекомендовал в универе бывший препод, который сейчас профессионально занимается MD в Германии. Осторожно: ОЧЕНЬ много математики (даже кватернионы есть:-)).

Кстати, молекулярная динамика--это не только расчет траектории движения одной системы в фазовом пространстве, но и расчет распределения систем по состояниям фазового пространства при заданных внешних условиях. И там совсем другие методы.
А я вот все расстраиваюсь: не то это будущее( Ни тебе телепортов, ни полетов к звездам. Да и АИ тоже нет пока.
Нет, к сожалению, не пробовал. Дело в том, что вместо .Net я стал пользоваться матлабом в том конкретном случае, когда .NET не подошел, а в Матлабе в основном процедурная парадигма. Хотя и ООП, и функциональные фишки поддерживает, но они там не основные.
Так вы же IL меняете, сразу как у себя приложение собираете. Поэтому они будут работать так же, как если бы вы руками писали каждый раз Trace.WriteLine(«blah-blah»). Если с АОП не будет работать,, то и без него тоже.
Или я что-то не так понял?
Вы не подумайте, я знаю проектирование с ООП, и читал Gang Of Four, Фаулера и МакКоннела. Но оказывается, что серебряной пули нет. Это я и хотел донести.

В качестве еще одного аргумента против ООП в некоторых случаях выступает следующий: часто очень удобно даже большие системы писать в специализированных системах, например, в MATLAB (вот тут много подтверждений User stories). Потому что в Матлабе есть тысячи полезных, быстрых и оттестированных функций, которых нет ни в одной библиотеке в Java, .Net или C++ (они, может, и есть, но не такие хорошие, и не в одной библиотеке, а в сотне разных. и с багами) и удобная среда.

И MATLAB, в общем-то, плохо поддерживает ООП.

Поэтому проще писать процедурно в матлабе, чем с ООП на C++.

Но самое главное: Матлаб неспроста плохо поддерживает ООП. А причина описана в комментарии выше (ООП--хорош для приложений с Entity-Relationship model)
Я для себя недавно открыл (хоть 3 года разрабатываю корпоративные веб-приложения с .Net и ООП), что многие научные приложения писать с помощью ООП--ОЧЕНЬ тяжело.

ООП подходит в основном для корпоративных приложений, где число сущностей конечно или счетно и где работает Entity-Relationship model.

Как только вы работаете с множествами несчетными (функции, векторные пространства, многообразия) (то есть в естественных науках и нормальных инженерных приложениях, не CMS/e-commerce приложениях), ООП--это не всегда лучшее решение, потому что оно концептуально не подходит. Большую часть времени вы потратите на glue code.
И тогда окаывается, что процедурное программирование намного лучше.

Хотя не спорю, во многих научных расчетах ООП будет удобней процедурного подхода.
По поводу статьи возникает куча вопросов:
1. точно ли однократна запись 2. насколько быстро срабатывает сознание по сравнению с подсознанием 3.единственной ли функцией обладает подсознание и тд.

Фрейд (куда ж без него), если я не ошибаюсь, утверждал, что подсознание регулирует процессы, вытесняемые сознанием (сексуальное желание). Но вполне может быть, что оно делает это так же медленно и тщательно, как и сознание делало бы, не будь они вытесненными.

В общем, ссылки на источники явно будут не лишними.

Информация

В рейтинге
Не участвует
Откуда
Минск, Минская обл., Беларусь
Дата рождения
Зарегистрирован
Активность