LaTeX Project Public License 1.3a (#LPPL-1.3a) We have not written a full analysis of this license, but it is a free software license, with less stringent requirements on distribution than LPPL 1.2 (described next). It is still incompatible with the GPL because some modified versions must include a copy of or pointer to an unmodified version.

http://www.gnu.org/licenses/license-list.html.en#GPLIncompatibleLicenses

ну вот зачем нужно смешивать логику с представлением?

а на самом деле дело интересное..

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

Спасибо. Косяк. Учту.

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

Люди в этом треде с тобой не согласны.

аксиомой выводить результат в файлы, инклудить их в латех, собирать всё make файлом нельзя?

имхо правильно он говорит, надо или использовать document mode в CAS, ЯП или делать то, что я описал выше, встраивание ЯП в латех имеет смысл только для более упрощённой генерации документа.

Как при таком подходе вставить формулу в строку?

Если что-то можно сделать, это не значит, что это нужно делать.

Но вообще идея, похоже, здравая. Займусь реализацией.

\input{./files/formula_1}

если хочется пописать велосипеды, то можно собирать всё в файл вида

index:
latex stuff...
....

и написать латех модуль вытаскивающий формулу (текст) по индексу, тогда можно делать что-то вроде

\begin{equation}\label{foo}
   \use_file{index_foo}
\end{equation}

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

Проект признаю сырым, тему помечаю как решенную.

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

То есть, использование при сборке опции -shell-escape делает смену лицензии бессмыссленной?

Глупость написал. Можно будет сделать без -shell-escape, если сначала распарсить tex файл внешним скриптом и сгенерить файлы для инклюда, и только потом собирать.

Также хотелось бы увидеть уважаемого Evgueni по вопросу вывода графиков в файл с помощью axiom или его форков.

не разбираюсь в лицензиях на таком уровне.

Есть org-babel, помимо прочего вроде дружит с Мaxima / Octave / R / Matlab.

И Sage.

Он не решает задач вывода рассчетов на печать в типографском качестве в соответствии со стандартами (ГОСТ, например), а привязка к latex может это позволить

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

Я к сожалению в этом вопросе не спец. Я думаю, что если с английским проблемы, чтобы задать вопрос на форуме, то спроси Андрея Грозина. E-mail можно найти по ссылке: http://www.inp.nsk.su/structure/people.ru/show_people.ru.shtml?%E7%D2%CF%DA%C...

Спасибо, уже нашел решение.

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

1. Пересчитать значение для исправленных данных.

2. Если оно используетя в дальнейших расчётах, пересчитать все зависимые величины.

3. Найти все вхождения этих данных в отчёте, включая таблицы и графики и исправить их.

4. На всякий случай всё ещё раз десять раз проверить.

5. Ответить на письмо из головной организации: почему в разделе 3.2.4 Kjc=102.7, а оно же в таблице 7.2.3 равняется 103.8.

6. Подумать как бы сделать так, чтобы исключить саму возможность подобного рода ошибок.

7. Вспомнить о грамотном программировании.

8. ????

9. Выгода.

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

О, хорошая мысля: можно и Octave таким же способом «прикрутить» к латеху.

А оно на самом деле так и делается.

☺

Вспомнил, как переписывал ТЗ: везде поизменял цифры, а картинку перерисовать забыл (а там старые значения были обозначены).

Пока делается не так

Это было актуальное замечание. У меня выхлоп axiom включался в latex минуя файлы при компиляции. Точнее была пара промежуточных файлов. Но если сделать так, как сказал qnikst, то потом результат расчетов можно будет собрать на машине, где не установлены эти скрипты и/или axiom.

Достаточно грамотно написать «нутро» команды \axiom.

Томика Кнута для этого хватит за глаза.

Я в курсе. Просто в самом начале у меня было неверное планирование архитектуры проекта. Теперь я получил необходимую критику, и вижу, что нужно сделать. Как это сделать я знаю.

это излишнее переусложнение, тем более котлеты и мух лучше держать отдельно. Вариант объединения латеха с кодом логичен только внутри CAS, но не наоборот, если CAS поддерживает это, да и то это скорее для презентационных примеров.

Когда перепишу - кастану тебя в тред. Годные советы даешь.

И тебя кастану. Тоже делные советы, хотя и непонятным языком.

не вижу

в расчётах и в тексте используются одни и те же данные.

как вариант со спагетти кодом

откуда ты нафантазировал спагетти код?

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

*дельные \\самоfix

в расчётах и в тексте используются одни и те же данные.

а в предложенным мной прям такие разные данные, что диву даёшься ;)

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

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

а в предложенным мной прям такие разные данные, что диву даёшься ;)

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

Вариант пох потому, что каша из кода и представления мешает адекватному восприятию и редактированию файла.

Именно, что пох. :-) Ты сейчас думаешь в контексте программирования, а это большая ошибка. Правильно думать об этом, как о написании статьи.

В общем, мне проще показать как это сделано правильно в схожим инструменте.

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

т.е. вводить make сложно?! офигеть.. на самом деле, чтобы велосипед был удобным нужна поддержка удобной загрузки данных из внешних файлов в латех, ну и генерилка make файла.

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

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

тобы велосипед был удобным нужна стройная система костылей и подпорок. Ну и дополнительные боковые колёсики.

Написание статьи представляет из себя две независимые части

Только в теории.

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

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

Только в теории.

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

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

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

use texmacs, luke.

уже объяснил, почему не подходит