Честно говоря, в первый раз слышу такую идею. Даже в Рихтере (CLR via C# который) про такое не пишут, кажется. Я не совсем понимаю, почему GC будет быстрее, чем С++ деаллокация, если собирает большими объемами. Вот почему будет медленее легко можно сказать: нужно остановить рабочий поток, запустить GC, протрекать, на какие объекты есть ссылки из стека (пройти весь стек, дерево объектов), записать адреса объектов в очередь freachable, и т.п. Я согласен, что если делать GC редко и удалять много, то вроде бы будет быстрее, чем если делать GC часто и удалять мало. Но это все равно будет медленнее, чем детерминистическая деаллокация С++, при которой просто вызоваются деструкторы в нужных местах (которые все равно будут вызываться при GC). Короче, деструкторы всегда в сумме займут одно и то же время, а вот оверхед есть только в GC.
В обеих статьях, мне кажется, упускают как минимум garbage collection. Даже если весь ассемблерный код, кроме деаллокации, будет идентичным, C# будет медленнее (тестов у меня, конечно, нет, и все зависит от «паттернов» аллокации-деаллокации, но тем не менее). Кроме того, задержки будут происходить в непредсказуемое время.
1. Я не про бинарник, а про исходный код.
2, 3. Я знаю. Но если с помощью boost bcp вытащить только то, что нужно, к примеру, для boost array, то получается 2.9 Мб исходного кода (проект начинался еще до C++11).
<да начнется холивар> А я вот с некоторых пор стараюсь избегать буст, потому я хочу, чтоб код был самодостаточным (компилировался сразу после загрузки из системы контроля версий)—то есть буст надо класть в код—но даже минимальные плюшки из него, типа boost::array (хотя он уже не актуален), обычно тащат за собой мегабайты кода. Впрочем, я не уверен, сколько тащит boost::size.
Мне кажется, писать тесселяцию (особенно больших мешей) на C#—довольно рискованно само по себе. Хотя, конечно, С++ трудностей добавит.
Лицензия, наоборот, пермиссивная—вы можете делать с кодом, по сути, что угодно, только указывать в дистрибутиве и рекламе, что внутри используется qhull.
Мне кажется, это не та задача, которую вы быстро решите сами. Вроде как там очень много подводных камней, например, со случаями, когда несколько точек находятся в одной плоскости или близко к ней (и начинают влиять ошибки округления). Я понимаю ваши ограничения, но это не тот случай, мне кажется. Этот код открыт, он работает с 1996 года, у научной статьи, в которой описана идея быстрой реализации тесселяции, более 2000 цитат. Поддержка там, в общем-то, не требуется. Именно этот код используется, как я сказал (судя по их сайту), в R, Mathematica, Matlab, Octave, так что сомневаться в нем не приходится. В конце концов, вы можете просто включить исходники в проект. Это выглядит как реклама, но, опять же, мне кажется, вы просто потеряете очень много времени совершенно напрасно.
А если не секрет, почему вам не подходит, в общем-то, стандартная реализация тесселяции Делоне, qhull? Быстрый, надежный, справляется со всеми подводными камнями, ошибками округления и т.п. Матлаб, к примеру, использует именно эту библиотеку под капотом.
Все издания, с которыми я сталкивался, допускают Word тоже. Но обычно пишут, что Tex им больше нравится. Основная причина долгоживущей популярности в том, что многим исследователям он тоже больше нравится. Я написал три статьи в Word (мой профессор один из тех, кто Tex не знает), но мы сотрудничаем с другим институтом для другой статьи, и их проф сказал, что признает только Tex. И вот мне пришлось писать на Tex, и я очень доволен, собираюсь продолжать.
Причин много: 1. чистый текст—это хорошо (можно копировать, сравнивать версии, заменять регекспом) 2. вы концентрируетесь на тексте, не на оформлении 3. Tex делает за вас рутинную работу (нумерация и ссылки на формулы, главы, библиографию). В ворде можно все это делать, но намного неудобнее (для формул надо ставить макросы или mathtype, для библиографии zotero или mendelay; mathtype глючный, у них есть критические баги—они сами признали в переписке, я однажды переделывал все формулы; макросы для формул иногда конфликтуют с zotero; если вы перенесете главу, то все ссылки на нее испортятся).
А если вы верстаете диссертацию, то Word—это позор, потому что его typesetting, типографика, никуда не годятся. Вот очень наглядное сравнение.
Мой коллега однажды написал очень неплохой, как мне кажется, сборник советов и рецептов про latex. Там есть про microtype, оформление библиографии и другое. Вероятно, читателям этой статьи тоже будет интересно.
Кроме того, мне кажется, на рисунках можно поправить некоторые вещи: (1) расстояния между «коробкой» рисунка (черным квадратом), подписями к осям и значениями на осях можно делать значительно меньше. (2) Расстояния «коробка-числа на осях» и «числа на осях-подписи к рисунку» можно сделать одинаковыми или соразмерными (сейчас вторые намного больше первых). (3) Подписи лучше выравнивать по «коробке», а не по всей ширине/высоте рисунка (коробке + подписям осей). (4) На трехмерном рисунке значения налазят на ось и друг на друга. (5) Кроме того, минимальное значение по оси z можно сделать намного меньше. (6) Еще я заметил, что нынче в западных физических журналах почти никогда не рисуют сетку (даже в логарифмических шкалах), просто оставляют ticks на осях—видимо, чтоб не захламлять рисунок и не отвлекать внимание.
Я пытаюсь делать кандидатскиую в Германии, и к нам на (химический) факультет тоже водят периодически детей, судя по виду, из детского сада. Мне тоже это очень понравилось.
Ну тут дело не в языке, а в том, на чем я, как разработчик и человек, читающий код, хочу сосредотачивать свое внимание. Кстати говоря, подход, предложенный выше, очень интересный. Можно его даже расширить и каждому классу или файлу ставить в соответствие соседний класс или файл, где содержатся только обработчики ошибок.
Я думаю, это не поможет. Софт в исследовательских проектах очень быстро меняется, потому что это исследовательские проекты. Вы очень примерно представляете, какие данные вы получите в результате проекта. Или даже сегодня к обеду. Именно поэтому это называется исследованиями. Затраты на коммуникацию между, к примеру, физиком и программистом будут настолько огромными и неудобными, что в большинстве случаев все равно физик будет писать свой код. Поэтому ребята в статье и предлагают как-то повышать уровень культуры программирования непосредственно среди ученых.
Очень странная статья, на мой взгляд. Те, кто все это знают, ничего нового не найдут. А тем, кто что-то здесь не знает, разобраться, мне кажется, нереально. Нет вступления, заключения, введения. Нет пояснений, нет интерпретации символов (c, d, Q? что это?). Нет разбиения по разделам. Где заканчиваются и начинаются разделы? Есть ли подразделы? Нет выделения конечных результатов. Что такое «xfiles», опять же? Кажется, что это какой-то черновик конспекта лекций. А можно было бы сделать хорошую статью. Например, написать, в чем преимущества и недостатки разных представлений, где они используются и т.п.
А если еще немного подумать, то получается, что любой фотон—поскольку обладает массой и энергией—искривляет пространство-время и потому влияет на фотоны, пролетающие рядом. А те, в свою очередь, на него, хоть и очень слабо. Так что это—возможно—в каком-то смысле правило, а не исключение.
2, 3. Я знаю. Но если с помощью boost bcp вытащить только то, что нужно, к примеру, для boost array, то получается 2.9 Мб исходного кода (проект начинался еще до C++11).
Лицензия, наоборот, пермиссивная—вы можете делать с кодом, по сути, что угодно, только указывать в дистрибутиве и рекламе, что внутри используется qhull.
Причин много: 1. чистый текст—это хорошо (можно копировать, сравнивать версии, заменять регекспом) 2. вы концентрируетесь на тексте, не на оформлении 3. Tex делает за вас рутинную работу (нумерация и ссылки на формулы, главы, библиографию). В ворде можно все это делать, но намного неудобнее (для формул надо ставить макросы или mathtype, для библиографии zotero или mendelay; mathtype глючный, у них есть критические баги—они сами признали в переписке, я однажды переделывал все формулы; макросы для формул иногда конфликтуют с zotero; если вы перенесете главу, то все ссылки на нее испортятся).
А если вы верстаете диссертацию, то Word—это позор, потому что его typesetting, типографика, никуда не годятся. Вот очень наглядное сравнение.
Кроме того, мне кажется, на рисунках можно поправить некоторые вещи: (1) расстояния между «коробкой» рисунка (черным квадратом), подписями к осям и значениями на осях можно делать значительно меньше. (2) Расстояния «коробка-числа на осях» и «числа на осях-подписи к рисунку» можно сделать одинаковыми или соразмерными (сейчас вторые намного больше первых). (3) Подписи лучше выравнивать по «коробке», а не по всей ширине/высоте рисунка (коробке + подписям осей). (4) На трехмерном рисунке значения налазят на ось и друг на друга. (5) Кроме того, минимальное значение по оси z можно сделать намного меньше. (6) Еще я заметил, что нынче в западных физических журналах почти никогда не рисуют сетку (даже в логарифмических шкалах), просто оставляют ticks на осях—видимо, чтоб не захламлять рисунок и не отвлекать внимание.