Часть описаний на английском, а часть на русском - это не есть гуд.

Их там не больше десятка, я гарантирую это. Просто на сегодня устал переводами заниматься.

Респектище за проделанную работу.

Хорошая, годная статья. Было бы неплохо, если бы в нее добавили материал из
http://www.linux.org.ru/wiki/en/LOR-FAQ-Scientific

ты случаем не кандидатскую пишешь?

Годно, очень годно!

Ссылки в гугл зачем?

Ну тут как бы часто проскакивает, что «не отсылайте меня в гугл, мне надо на русском, я искал, там нет».
Вот пусть будет пример того, как надо искать, чтоб было.

Молодец,дови плюс в кар...я хотел сказать в ЧСВ:-)

спасибо за хороший обзор

Аватарка органично сочетается с комментом :)

По теме: автору большой респект за проделанную работу.

зри в корень, о провидец..

Есть одна идея. Возможно, стоит сделать перед полным содержанием краткое (Только первые два уровня). Сопровождать будет не так сложно — реструктуризация вряд ли будет частой.

И спасибо за труды. Нанотех^W потомки не забудут =)

Это как, можешь показать на примере статьи из песочницы?

Я кажется понял: сделать краткое содержание списком, а в нём ссылки на разделы, верно?

http://www.linux.org.ru/wiki/en/User:jeuta/%D0%98%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D0%BE%D0%B5_%D0%9F%D0%9E

Сделал через «внешние» ссылки (гвоздями прибито к www.linux.org.ru). Не изучал все возможности нашей JAMWiki...

> Прошу сознательных ЛОРовцев просмотреть статью, выразить своё мнение по поводу того, как улучшить навигацию (да, оглавление ооооочень длинное, знаю), напомнить, что можно ещё с ходу добавить.

Сделай навигацию несколькими страницами, т.е. те иерархии что у тебя сейчас есть 1,2,3... 1.1, 1.2.. и т.п. разнеси по отдельным страницам. Должно получиться более читабельно, а то сейчас там даже наличие интересующего тебя раздела нужно искать через Ctrf+F.

Посмотри, попытался немного исправить. Делать много страниц нет смысла, софт часто перекликается. Лучше держать на одной странице, так проще если в комментарии к одной софтине упоминается другая и наоборот.

Спасибо за идею, посмотри, как я сделал.

Обновил в своей песочнице. Вполне удобоваримый вариант. Жаль, JAMWiki оставляет # в ссылках...

Вот для таких вещей нужны irc и прочие. Отлично.

Да, стало получше. Хотя я немного не понял смысла разносить отдельными заголовками gVim и подобное(что сейчас без описания), в планах добавить его?

п.с. и да, стоило бы исправить gVim на Vim, т.к. gVim лишь гуёвая обёртка к виму.

не понял смысла разносить отдельными заголовками

Это сделано для того, чтобы тот, кто захочет внести свою лепту, мог просто нажать [Edit] у того подраздела, который готов править, а не выискивать в простыне в списке, порой зачем-то напичканной ненужными <br> и ещё всяким.
Так удобней ИМХО.

>>что сейчас без описания

Конец страницы вообще куцый вышел, его по хорошему в отдельную статью и надо (IDE и системы контроля версий), там я планирую что-то написать или что кто-то напишет.

Оглавление - неоправданная простыня. Нужно спойлером сделать.

Лучше пачкой спойлеров - для каждого подпункта.

Сам знаю, что спойлер там был бы уместен. Но в JAMWiki его нет и не планируется. В feature_requestor'e JAMWiki эту просьбу разраб закидал навозом. Соответственно встроенной возможности нет - нужен js, его надо написать, поклянчить Макскома, чтоб он его включил и т. д.

Но во-вторых, оставил так, чтобы тот, кто захочет внести свою лепту, мог просто нажать [Edit] у того подраздела, который готов править, а не выискивать в простыне в списке, порой зачем-то напичканной ненужными <br> и ещё всяким.
Так ещё проще откатывать правки, спроси у dn2010 и JB сколько раз они откатывали правки uju в простыне без разбору: где по делу исправлено, а где нет, увидели только то, что не по делу, и откат. А там весомая правка была в другом месте. С таким подходом коммитить в L.O.R. Wiki желание быстро пропадает.
Я лично решил для себя этот вопрос, внося в такие спорные трепетно «оберегаемые» статьи в комментарии, чтоб потом оттуда тот, кто эту статью курирует внёс.
В своей статье решил оставить такую структуру, пойдя на сделку с совестью, ибо выглядит это оглавление ужасно, но такое количество разделов нужно ИМХО, повторюсь, для простоты правки.

О, круто! То, что нужно...

По поводу структуры: когда статья будет наполнена максимально возможным количеством софта, структуру заголовков приведу в соответствие к статьям Linux в школе и Программы для дома и работы — то есть подзаголовок->список.

Есть мнение, что пора.

Я выше аргументировал, почему пока не буду этого делать. Вот сейчас aol и uju вносили правки, как думаешь, им удобней было внести их в кусок разметки из пяти строчек или из сотни?

дадада, плюсую! я б портянку править не стал! %)

Ясно.
Сколько софта... Неужели ты составлял список с нуля? Или за основу взят аналогичный, англоязычный?

Таки дописал? Поздравления

Неужели ты составлял список с нуля?

Yep.

А что, в кандидатской можно провести сравнение нескольких инструментов для определённой узкой ТЗ и это проканает?

А так вообще-то нет.

Мое уважение.
Просмотрел список, нашел несколько проектов, к которым буду присматриваться попристальнее в ближайшем будущем.

Можно про кантор перенести после максимы и r? А то кантор всё же оболочка для них, а описание идёт раньше

В «Инструменты для математических и научных расчётов» -> «Библиотеки» может широко известный в узких кругах cgal добавить?

Один маленький фикс:

gedasymbols.org — ресурс-репозиторий для обмена и расшаривания разработанных компонентов

Обмен и расшаривание - суть одно и то же. «Расшаривания» можно убрать.

Изначально так и было, luke, Cantor был почти последним в том разделе, перенёс его выше я от того, что старался расположить к примеру все либы Python подряд, всё символическую алгебру подряд, все комбайны подряд. Вот потому Cantor оказался между Sage и SMath Studio. Потому что тоже с намёком на универсальность.

Просто он потеряется, если его указывать аж после всей кучи стат пакетов.

CGAL там есть в статье в принципе, но я его пхнул в Системы визуализации данных->Библиотеки зачем-то. Если вы какое-никакое напишите описание взамен английской копипасты, я перенесу :)

fixed
Спасибо

ЧСВ, пацан к успеху шёл

Кстати, забавно, статья из песочницы, User:adriano32/Инженерное ПО четвёртая в результатах гугла на запрос «Инженерное ПО» без кавычек. Комментарии к этой статье в песочнице, User comments:adriano32/Инженерное ПО на второй странице результатов, а собственно, добавленная вчера вечером статья Инженерное ПО на третьей странице результатов.

CGAL - это открытая библиотека, написанная на языке C++, реализующая множество структур данных и алгоритмов вычислительной геометрии. В библиотеке реализованы различные методы триангуляции и построения диаграмм Вороного, операции над треугольниками и многогранниками, алгоритмы генерации сеток, алгоритмы геометрической обработки (geometry processing), структуры и алгоритмы разбиения пространства и поиска, алгоритмы оптимизации, а также другие алгоритмы.

Код достаточно хорошо оптимизирован и сопровождается адекватной документацией. Библиотека распространяется под лицензией QPL (частично LGPL).

И кстати да, в содержании в пункте 5 ссылка «Библиотеки» не работает.

Спасибо, добавил твоё описание, перенёс из визуализации в библиотеки для математических и научных расчётов.

It is well known bug :)
В любом случае, спасибо за наблюдательность и взнос.

It is well known bug

Почитал тред по ссылке - как страшно жить :)

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