LINUX.ORG.RU

Ищу редактор, показывающий формулы в коде по-человечески


0

1

Существует ли редактор для исходников, который бы изображал математические выражения так, как они обычно выглядят на бумаге? То есть как минимум с многоэтажными дробями, а желательно и со степенями в виде верхних индексов и прочим.

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

Подчёркиваю, это не формулы сами по себе, а выражения в программе на неком ЯП. Т.е. нечто вроде «double A = 1.3 / (R+t) + (k + f) / (t + L/a);»

Бывает такое?

★★
Ответ на: комментарий от AIv

Хватит писать чушь. Набирать формулы проще plain текстом (не надо запоминать тысячу хоткеев или тыкать мышкой выбирая нужный оператор), читать и редактировать формулы удобнее в wysywyg-представлении. По-этому, если стоит задача написания write-only кода, который потом читать и поддерживать не надо (например - верстка статьи в техе) можно обойтись обычным текстом, во всех остальных случаях абсолютное большинство предпочитает использовать естественную математическую нотацию (загляни в любой учебник по математике и убедись, если не веришь).

anonymous
()
Ответ на: комментарий от anonymous

во всех остальных случаях абсолютное большинство предпочитает использовать естественную математическую нотацию

Все верно. Именно поэтому уважающий себя человек, если хочет подготовить текст с формулами, который в дальнейшем нужно будет иметь возможность изменять, будет пользоваться только латехом или техом. А идиот воспользуется каким-нибудь «вордом» или дрянью вроде ликса.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Именно поэтому уважающий себя человек, если хочет подготовить текст с формулами, который в дальнейшем нужно будет иметь возможность изменять, будет пользоваться только латехом или техом.

Конечно, нет. практика неоднократно подтвердила, что редактировать код на порядок удобнее в wysywyg, а простой текст - это «написал и забыл». Сей факт можно даже строго доказать, если угодно.

anonymous
()
Ответ на: комментарий от anonymous

редактировать код на порядок удобнее в wysywyg

Жесть! Если вам удобнее вместо того, чтобы набрать несколько символов, мучиться с мышкой и клавосочетаниями, теряя уйму времени на ненужные вещи, а все лишь ради «красоты», то вы явно относитесь к тем 95-процентам =)

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Жесть! Если вам удобнее вместо того, чтобы набрать несколько символов, мучиться с мышкой и клавосочетаниями, теряя уйму времени на ненужные вещи, а все лишь ради «красоты», то вы явно относитесь к тем 95-процентам =)

Не понял, о чем ты? Зачем мучаться с мышкой, клавосочетаниями и терять уйму времени? Какие-то сказки. Давай по порядку, допустим у нас есть формула и нам следует ее исправить. Тогда мы должны выполнить следующие шаги:

1. распарсить и прочитать формулу

2. найди место исправления

3. перейти к месту исправления

4. собственно сделать исправление

5. сохранить результат

Так вот, пункты 2,3,4,5 в обоих случаях (при редактировании в wysywyg и в представлении обычным текстом) совершенно идентичны. Разница идет только в п.1: «распарсить и прочитать формулу». А читать удобнее формулы, записанные в стандартной мат. нотации. Если бы это было не так - никто бы этой нотацией не пользовался, писали бы теховский plain text. Если при редактировании в wysywyg первый пункт выполняется проще, а остальные - так же, то какой отсюда следует сделать вывод?

anonymous
()
Ответ на: комментарий от anonymous

Если при редактировании в wysywyg первый пункт выполняется проще, а остальные - так же, то какой отсюда следует сделать вывод?

Вывод делайте какой угодно. Но во-первых, ни один wysywyg-редактор (если он, конечно, не транслирует все в латех) не способен выдать нормальную человеческую верстку. Во-вторых, если он транслирует выхлоп в тех/латех, то код получается таким, что его можно править только этим редактором. Что не есть хорошо: пошлете вы такой код кому-нибудь, а он его отредактировать не сможет, т.к. не имеет нужной программы. А установить ее по той или иной причине не может.

Так что, если пользоваться этими дебильными wysywyg, ваш текст будет доступен только вам.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Crow

ТеХ нужен только самую малость (если собираетесь делать свои стилевые файлы или автоматизировать какие-нибудь процессы - например, у меня теховский макрос автоматом делал бланковые тесты и шаблон с правильными ответами), обычно хватает латеха.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

Но во-первых, ни один wysywyg-редактор (если он, конечно, не транслирует все в латех)

А почему бы ему не быть латехом?

Во-вторых, если он транслирует выхлоп в тех/латех, то код получается таким, что его можно править только этим редактором.

Как это так, если трансляция туда-сюда однозначна? Мы факту пишем тот же тех, просто сразу видим формулу, а не простой текст.

Что не есть хорошо: пошлете вы такой код кому-нибудь, а он его отредактировать не сможет, т.к. не имеет нужной программы.

Так пусть установит.

Так что, если пользоваться этими дебильными wysywyg, ваш текст будет доступен только вам.

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

anonymous
()
Ответ на: комментарий от anonymous

А почему бы ему не быть латехом?

Вы видели, что представляет из себя латеховский файл, создаваемый опенофисом (экспорт->латех)? Прочитать его невозможно. Это как html-файлы, которые некоторые идиоты всякими wysiwyg-редакторами создают...

Как это так, если трансляция туда-сюда однозначна?

Одну и ту же формулу вы можете записать кучей вариантов. Текст, кстати, тоже: вы можете написать «текст», а дебильный wysiwyg-редактор экспортирует это в «\cyrt\cyre\cyrt\cyrk\cyrs\cyrt» или что похуже :)

Так пусть установит.

А может, у него архитектура не-x86, или программа платная - зачем выкидывать деньги коту под хвост? Или операционка совсем другая?

этот wysywyg дебилен, потому что после дождичка в четверг может возникнуть такая ситуация, что одна формула из 1000 будет слегка непонятна человека, который будет читать этот код без wysywyg

Не надо искажать мои слова: «код», генерируемый wysiwyg, вообще нечитаем.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Вы видели, что представляет из себя латеховский файл, создаваемый опенофисом (экспорт->латех)? Прочитать его невозможно.

Как из того, что open office работает хреново, следует то, что такое не может работать нормально в принципе?

Одну и ту же формулу вы можете записать кучей вариантов.

Вообще говоря, ничего транслировать не надо. Ты же на простом латехе пишешь. Редактор просто находу рендерит формулу. Ту же wolfram mathematica видел, например? Там однозначная трансляция, так что ничего невозможного тут нет.

А может, у него архитектура не-x86, или программа платная - зачем выкидывать деньги коту под хвост? Или операционка совсем другая?

А может быть он марсианин.

Не надо искажать мои слова: «код», генерируемый wysiwyg, вообще нечитаем.

Ну что же поделать, я _вынужден_ исказить твои слова так, чтобы они соответствовали реальным фактам. Потому что в оригинале они этим фактам противоречат. Вот и по последнему, верно будет: «код, генерируемый open office, совершенно нечитаем».

anonymous
()
Ответ на: комментарий от anonymous

Ты же на простом латехе пишешь. Редактор просто находу рендерит формулу.

Проблема в том, что нужен полноценный ИИ, чтобы генерировать удобочитаемый латех.

Обратный же процесс очень прост. Например, для вставки незначительного количества формул/табличек в html (в т.ч. во всякие форумы, не поддерживающие латеха), я использую простенький скрипт:

#!/bin/sh
if [ "$1" = "" ]; then
	echo "usage: $0 <latex string without \$s>"
	exit
fi
[ "$2" != "" ] && pngname="$2" || pngname="out.png"
mask=tmp_$$
texfile=${mask}.tex
cat > $texfile << EOF
\documentclass[12pt]{minimal}
\usepackage[english, russian]{babel}
\usepackage[koi8-r]{inputenc}
\usepackage[matrix,arrow,curve]{xy}
\usepackage{amsmath}
\usepackage{amsfonts}
\begin{document}
\setbox0=\hbox{$
EOF
echo "$1" >> $texfile
cat >> $texfile << EOF
$}
\textwidth=\wd0
\textheight=\ht0
\advance\textwidth by 2em
\advance\textheight by 2\dp0
\vbox{\vss\hbox{\hss\copy0\hss}\vss}
\end{document}
EOF
latex $texfile
dvipng -D 600 ${mask}.dvi -o $pngname
rm -f ${mask}*

Например, для

makeformula "\displaystyle\int\limits_0^\infty\frac{\sin x}{x}dx=?"
получается такая штука. Естественно, можно и для простого редактора «замутить» такую компиляцию формул «на лету», как только вы поставите завершающий доллар. Только зачем?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Проблема в том, что нужен полноценный ИИ, чтобы генерировать удобочитаемый латех.

Его _вообще не надо_ генерировать, я уже хз какой пост пытаюсь до тебя эту простую мысль донести. В редакторе и так все хранится в виде латех кода, просто при выводе на экран код сразу парсится и рендерится.

Только зачем?

За тем, что удобнее читать уже отрендеренные формулы, чем латех-код. Человеческое время стоит дороже машинного - если распарсить код может машина, то зачем этим заниматься мне? Пусть машина это и делает.

anonymous
()
Ответ на: комментарий от anonymous

а тем, что удобнее читать уже отрендеренные формулы, чем латех-код. Человеческое время стоит дороже машинного - если распарсить код может машина, то зачем этим заниматься мне? Пусть машина это и делает.

А набрать latex file или pdflatex file не позволяет религия?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> можно и для простого редактора «замутить» такую компиляцию формул «на лету», как только вы поставите завершающий доллар. Только зачем?

Зачем же генерить при завершающем долларе? Можно сразу после \int по хоткею сгенерить значок интеграла и пустые поля для подстановки выражений пределов/подинтегрального выражения/дифференциала.

anonymous
()
Ответ на: комментарий от anonymous

Можно, но не нужно: в сложных формулах будет неудобно перемещаться между областями ввода. Хотя, конечно, кому-то это может и понравиться.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> А набрать latex file или pdflatex file не позволяет религия?

Так мне не надо узнавать, во что рендерится формула, мне надо распарсить сам код латеха, чтобы узнать в каком месте внести изменение. То, что я сделал pdflatex file и посмотрел на результат, мне в этом никак не поможет - я же не могу тыкнуть мышкой/перейти при помощи клавиатуры к подинтегральному выражению и сразу сделать правку? Мне придется искать в коде, где записано это подинтегральное выражение.

anonymous
()
Ответ на: комментарий от Eddy_Em

> Можно, но не нужно: в сложных формулах будет неудобно перемещаться между областями ввода.

Уже лет 40 подобные вещи решаются при помощи 1 (прописью: одного) клика мышки. Но если кому-то пользоваться мышкой при редактировании кода религия не позволяет - оно конечно да. Хотя, в 90% случаев между областями ввода даже при помощи одной клавиатуры перемещаться будет удобнее, чем между теми же областями в обычном коде между соседним областями можно будет 1 нажатием клавиши переместиться - с кодом так не получится). В остальных 10% случаев - так же удобно.

anonymous
()
Ответ на: комментарий от anonymous

> во всех остальных случаях абсолютное большинство предпочитает использовать естественную математическую нотацию

Абсолютное большинство (с учетом секретарш и домохозяек) предпочитает ворд и виндовс. Если для Вас позиция абсолютного большинства основной аргумент - сносите линукс. А по теме коллега Вам все разжевал уже и даже в рот положил, не буду повторятся...

AIv ★★★★★
()
Ответ на: комментарий от AIv

> Абсолютное большинство (с учетом секретарш и домохозяек) предпочитает ворд и виндовс.

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

anonymous
()
Ответ на: комментарий от Eddy_Em

> Можно к нужному участку перейти, тыкнув мышкой в dvi-файле, если пользуетесь kile'ом.

dvi-файле

если пользуетесь kile'ом

По сценарию я здесь должен злорадно рассмеяться, ведь так? О-хо-хо-хо-хо-хо.

anonymous
()
Ответ на: комментарий от anonymous

Я имел ввиду абсолютное большинство научных работников

Я так понял, вы к научным работникам не относитесь. Иначе такую чушь не говорили бы.

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

Ясен пень, кто ж вам исходники-то даст? Во всякие arxiv.org и журналы отсылаются исходники, а те уже выкладывают pdf.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Я так понял, вы к научным работникам не относитесь. Иначе такую чушь не говорили бы.

Это чушь? тогда пруфы, пожалуйста. На статьи/учебники/монографии с текстом вместо мат. формул.

Ясен пень, кто ж вам исходники-то даст?

А при чем тут исходники? Мы говорим о том, в каком формате формулы наиболее читабельны. Научная общественность высказалась вполне однозначно - формулы наиболее читабельны в виде... формул! Кто бы мог подумать, не правда ли? Ну а в процессе редактирования между wysywyg и редактированием кода разница только в одном, как мы уже выяснили, - в первом случае мы читаем формулу как формулу, во втором случае - парсим код.

anonymous
()
Ответ на: комментарий от anonymous

Да, еще один момент. Статьи/монографии/учебники - это как раз write-only, о чем я и говорил в самом начале. Тут, в отличии от написания программного кода, проблемы читабельности и поддерживаемости не стоит. Или, по крайней мере, она стоит намного менее явно и не заметна по сравнению с другими. По-этому на первый план выходит именно скорость написания, а не чтения и редактирования исходников. И тех вполне годно тут решает свою задачу, как инструмент для компьютерной верстки. Но не инструмент для написания программных продуктов.

anonymous
()
Ответ на: комментарий от anonymous

>> Абсолютное большинство (с учетом секретарш и домохозяек) предпочитает ворд и виндовс.

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

Если Вы имеете ввиду чтение текста - то да, и я сам предпочитаю читать уже собранный пдф. Но тут вроде говорят о наборе и верстке текста? И Ваш аргумент некорректен - давайте говорить о позиции абс большинства людей набирающих и редактирующих тексты.

Так вот, я выше писал о своем скромном личном опыте (можете покопать) - и ни я, и никто из тех кого я лично знаю визиви при наборе верстке в техе не используют, причем это вполне осознано - визиви менее удобен. Все мои аргументы изложены выше, повторятся лень - если Вам это интересно можете прочитать, если нет... лично меня Ваше мнение в данном вопросе совершенно не интересует, поскольку Вы явно не в теме.

AIv ★★★★★
()
Ответ на: комментарий от AIv

> Если Вы имеете ввиду чтение текста - то да, и я сам предпочитаю читать уже собранный пдф. Но тут вроде говорят о наборе и верстке текста?

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

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

Я тоже не использую, и? Речь не о верстки статьи, речь о написании программного продукта/библиотеки. Вы понимаете разницу? вот есть некоторая научная статья, в ней формулы. Вы ссылаетесь на эту статью и в своей хотите упомянуть те же формулы, что вы сделаете? Правильно - набьете их заново, исходников-то у вас нет. Другой пример - вы пишете некоторую библиотеку и оказывается, что уже написана другая библиотека, в которой уже очень близко реализована часть требуемого функционала. Что вы сделаете? Возьмете ту библиотеку (исходный код), поправите то, что вам надо, и будете использовать. Понятна разница? При верстке документа и написании программного кода существенно разные приоритеты. ОП-пост как раз о написании программного кода, но не о верстке. Неужели идея о том, что инструмент, который вполне годен для выполнения одной задачи, может не быть так хорош в совершенно другой, настолько нетривиальна?

anonymous
()
Ответ на: комментарий от anonymous

> Да, еще один момент. Статьи/монографии/учебники - это как раз write-only, о чем я и говорил в самом начале. Тут, в отличии от написания программного кода, проблемы читабельности и поддерживаемости не стоит. Или, по крайней мере, она стоит намного менее явно и не заметна по сравнению с другими. По-этому на первый план выходит именно скорость написания, а не чтения и редактирования исходников. И тех вполне годно тут решает свою задачу, как инструмент для компьютерной верстки. Но не инструмент для написания программных продуктов.

Смеялся... Вы судя по всему совершенно не представляете ни издательского цикла, ни проблем которые при верстке встают. Так вот, верстальщик и наборщик - это две совершенно разные профессии. Трудозатраты на верстку при создании оригинал макета книги больше (иногда в разы) чем на набор текста. В бытность мою верстальщиком издательство МАИК Физматлит делало все в техе (как сейчас не знаю), причем визиви никто не юзал - неудобно. Если вы не в курсе, верстка - это как раз правка уже набранного текста.

AIv ★★★★★
()
Ответ на: комментарий от anonymous

Почитайте комментарии AIv'а. И не путайте конечный продукт с продуктом на стадии разработки.

А то сейчас еще начнете говорить, что софт удобно клепать не методом написания кода, а при помощи мышкотыкания всяких UML-диаграмм, которые потом транслируются в код =)

И еще, посмотрите на статьи в серьезных журналах (можете, например, воспользоваться поиском на adsabs.harvard.edu) - все они свертаны в латехе. Ручками. А не wysiwyg'ом.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AIv

Специально для тех, кто не в состоянии сам сделать пару логических умозаключений написано:

по крайней мере, она стоит намного менее явно и не заметна по сравнению с другими.

Для чтения и редактирования формул гораздо более удобна математическая нотация - это экспериментальный факт.

Так вот, верстальщик и наборщик - это две совершенно разные профессии.

Давайте уж будем последовательны - если отделить работу наборщика от работы верстальщика, то верстальщику вообще «внутрь» формул лезть не надо будет. Забиванием формул как раз занимается наборщик, у верстальщика несколько другие задачи и проблемы.

anonymous
()
Ответ на: комментарий от anonymous

> Неужели идея о том, что инструмент, который вполне годен для выполнения одной задачи, может не быть так хорош в совершенно другой, настолько нетривиальна?

Выше опять таки ТСу и Ко уже популярно объяснили, что их желания странны и противоестественны. Сложные алгебраические выражения в коде это сов отдельная история, есть два правильных подхода -

1) выражения тужа попадают из CAS (и вся правка вносится в CAS, итоговый код никто не редактирует) - это если алгебра дико сложная а производительность кода никого не интересует.

2) выражения в коде расписаны так подробно, что их легко редактировать в коде. Обычно так само происходит при оптимизации выражений, потому что компилятор хорошо оптимизировать алгебру не умеет. Если выражение в коде настолько громоздко что требует визиви для правки - автор кода был глубоко не прав и так делать никогда не надо.

AIv ★★★★★
()
Ответ на: комментарий от anonymous

исходников-то у вас нет

...

Возьмете ту библиотеку (исходный код), поправите то, что вам надо

Что-то у вас противоречивые какие-то высказывания =)

А вообще, я понятия не имею, зачем в коде писать формулы (а уж тем более - отображать их в графике) =) Ведь обычно алгоритм в формальном виде реализуется совершенно не так, как это записано на бумаге: используется рекурсия, итерации и т.п. Да и одну формулу можно разбить на части и вычислять при помощи нескольких функций. А в тех функциях, в свою очередь, пишутся довольно простые выражения, которые и так легко понятны. Например, чем непонятна эта строчка:

coef[k] = data[i]*filter[0] + data[i-1]*filter[1];
?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

> Давайте уж будем последовательны - если отделить работу наборщика от работы верстальщика, то верстальщику вообще «внутрь» формул лезть не надо будет. Забиванием формул как раз занимается наборщик, у верстальщика несколько другие задачи и проблемы.

Бред. Вы работали верстальщиком? Где?

AIv ★★★★★
()
Ответ на: комментарий от anonymous

если отделить работу наборщика от работы верстальщика, то верстальщику вообще «внутрь» формул лезть не надо будет. Забиванием формул как раз занимается наборщик, у верстальщика несколько другие задачи и проблемы.

А верстальщик даже не читает, что ему прислали - он просто «инклюдид» присланный код в общий макет. Он даже может латех знать лишь на самом минимальном уровне =)

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> И еще, посмотрите на статьи в серьезных журналах (можете, например, воспользоваться поиском на adsabs.harvard.edu) - все они свертаны в латехе. Ручками. А не wysiwyg'ом.

А с этим кто-то спорил? Я еще раз повторяю - верстка и написание программы это совершенно разные задачи. И проблемы при их решении возникают совершенно разные. И инструменты для их решения нужны - тоже разные. И если при верстке можно не обращать внимания на читабельность кода, потому что она не так важна по сравнению с другими аспектами, то в программировании так нельзя. Код на техе пишется для того, чтобы быть отрендеренным в конкретный документ, каковой документ и будут читать. Программный код пишется для того, чтобы потом этот код могли читать другие люди. Чувствуете разницу? Значение повторного использования существующего кода в программировании и верстке - несравнимо. Вам говорят - совать тонны нечитабельного кода в программный код это плохо, вы отвечаете - но ведь в теховский код суют же! Где тут логика?

anonymous
()
Ответ на: комментарий от Eddy_Em

> А верстальщик даже не читает, что ему прислали - он просто «инклюдид» присланный код в общий макет. Он даже может латех знать лишь на самом минимальном уровне =)

Об этом и речь. Задача верстальщика - это максимум оформить эту формулу «вокруг». А часто он о существовании этой формулы и не узнает. Так что здесь нужен инструмент, который позволяет быстро эту формулу набить и после этого к ней не возвращаться - что тех и выполняет прекрасно.

anonymous
()
Ответ на: комментарий от anonymous

Я про код уже выше писал. Повторюсь, если вам искать лень: в хорошем коде формулы не надо дублировать графически, т.к. в нем сложных формул, не понятных «с первого взгляда», просто нет.

А для увеличения удобства в хорошем коде есть комментарии.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Да, а тому кто баги устраняет в программах не обязательно знать ЯП - чего там, программа ж уже написана, ну где нить плюс на минус поменять, больших знаний тут не надо;-)

AIv ★★★★★
()
Ответ на: комментарий от anonymous

> Об этом и речь. Задача верстальщика - это максимум оформить эту формулу «вокруг».

Вы смешной все таки... люблю ЛОР, такие персонажи бывают. А ученый - это тогда задумчивое нечто с бордой и в очках, пишуший мелом формулы на своих черных от грязи манжетах и манишке, ага.

Как кого из бывших коллег-верстальщиков по физматилиту встречу, обязательно им Ваше мнение озвучу, они бедолаги и не в курсе что слишком много знают и вообще не туда лазют!

AIv ★★★★★
()
Ответ на: комментарий от AIv

> есть два правильных подхода

1) выражения тужа попадают из CAS (и вся правка вносится в CAS, итоговый код никто не редактирует) - это если алгебра дико сложная а производительность кода никого не интересует.

Костыль.

2) выражения в коде расписаны так подробно, что их легко редактировать в коде.

Так не бывает. Вы можете сколько угодно убеждать самого себя, что получившаяся лапша читабельна и удобна в редактировании, но это бред. Мат. нотация выстрадана поколениями математиков и сложилась такой, какой сложилась, в ходе эволюции. И она на порядок удобнее в чтении/редактировании всего, чего вы там себе ни напридумываете.

Если выражение в коде настолько громоздко что требует визиви для правки - автор кода был глубоко не прав и так делать никогда не надо.

Конечно, не надо - ведь нету никаких средств написать это выражение так, чтобы его потом можно было нормально прочесть. Если бы были - то исключительно так и следовало бы писать, т.к. по факту это наиболее удобный из существующих способ, и никакого другого способа, который хотя бы приблизился к этому по эффективности, не существует. И не появится в ближайшем времени. Что до ваших идиотских примеров из разряда 1/1/x = x, то все подобные упрощения будут сделаны еще во время вывода этого громоздкого выражения.

anonymous
()
Ответ на: комментарий от anonymous

Ах, да, следуя вашей логике вместо:

y = 1/1/x

надо писать:

y1 = 1/x, y = 1/y

anonymous
()
Ответ на: комментарий от AIv

Ну, не скажите: нам из всяких MNRAS'ов статьи возвращали, т.к. не могли что-нибудь скомпилировать. Просили исправить текст в соответствии с их собственным стилевым файлом и не пользоваться своими стилями.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Я про код уже выше писал. Повторюсь, если вам искать лень: в хорошем коде формулы не надо дублировать графически, т.к. в нем сложных формул, не понятных «с первого взгляда», просто нет.

Ну вот у нас такая задача, в которой такие формулы ЕСТЬ. Пока что вариантов предложено два - и оба костыльные. Либо пользоваться сторонним софтом для генерации кода, либо писать кучу невнятной лапши, которая столь же невнятна, как и просто огромное выражение, записанное plain текстом (на самом деле еще невнятнее, т.к. вы в итоговом выражении замените осмысленные входящие переменные на временные, для которых адекватные имена придумать будет невозможно). Это будет чисто механически проще отпарсить, но понять, что в результате делает полученный код - будет сложнее. Единственное решение проблемы - редактор с поддержкой мат. нотации, о котором автор и спрашивал.

anonymous
()
Ответ на: комментарий от AIv

> Как кого из бывших коллег-верстальщиков по физматилиту встречу, обязательно им Ваше мнение озвучу, они бедолаги и не в курсе что слишком много знают и вообще не туда лазют!

Ну, ок, ваши коллеги-верстальщики вместо того, чтобы заниматься собственно версткой, делают еще что-то. Хлебопек ведь не перестает быть хлебопеком от того, что сам мелет муку? Нет? Ну вот и ладненько.

anonymous
()
Ответ на: комментарий от anonymous

Во многих моих задачах формулы, описывающие реализации алгоритма, расписаны на несколько страниц. Однако в самих исходниках такого ужаса нет, да и функций длиннее половины экрана, тоже почти нет.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Вообще мне не ясно, вы хотите доказать, что сверстать журнальную статью и написать библиотеку - это одинаковые задачи?

anonymous
()
Ответ на: комментарий от Eddy_Em

> Во многих моих задачах формулы, описывающие реализации алгоритма, расписаны на несколько страниц.

И зачем в другую крайность кидаться?

Однако в самих исходниках такого ужаса нет, да и функций длиннее половины экрана, тоже почти нет.

Конечно, нет - ведь редактора, который бы такое поддерживал, не наблюдается :)

anonymous
()
Ответ на: комментарий от anonymous

Вы полностью меня поняли.

Допустим, есть у меня задача: кое-что посчитать. Я делаю подборку литературы, затем набрасываю алгоритм, а по нему уже пишу программку. Затем этой программкой пытаюсь обработать данные, попутно избавляясь от всяких багов. Когда получается удовлетворительный результат, пишу статью.

Конечно, написать программу для обработки этих самых данных - самый долговременный этап. Но не из-за того, что непонятно как с формулами разобраться, а из-за того, что эти формулы сначала надо получить, а затем еще и продумать, как распараллелить вычисления для их ускорения.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

При чем здесь редактор? Да физически многие формулы невозможно описать одним выражением на ЯП: нужны циклы, взаимодействия с параллельными процессами, взаимные вызовы функций, рекурсии и т.п.

Eddy_Em ☆☆☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.