LINUX.ORG.RU

Как правильно организовать процесс вычисления по формулам.

 , , вычисление


0

1

Пишу программу реализующую расчет из одного СНиПа. Расчет представляет собой последовательное вычисление по n различным формулам. Результаты передаются или в другие формулы или сохраняются как готовые. Кроме того, каждая формула пишет в лог в TeX нотации как она выглядит, с какими аргументами она вызвана и какой результат получен. Лог компилируется из TeXа в нужный строителям формат. Вопрос в том, как толковее организовать вычисления по формулам. Сейчас это объект Formulas, каждый метод которого реализует одну из формул, тянет из конфига описание данной формулы в TeXе и формирует объект Result, содержащий все необходимое для логгера. Сейчас все выходит очень некрасиво, так-как куча методов отличаются только числом аргументов и самим вычислением, которое они проделывают:

        public CalculationsResult aFormula(double alphaj, double m)  {
            double arr[] = {alphaj, m};
           double res = this.SolveCubic(1.4*alphaj, -(4.2*alphaj-1), 4.2*alphaj, -1-m);
           int id = 120;
           String name = new Object(){}.getClass().getEnclosingMethod().getName();
           HashMap l1 = GetArgs(name, arr);
           CalculationsResult result = new CalculationsResult(res, id, "a", l1);
           return result;
    }

Вопрос-то в чем?

kovrik ★★★★★
()

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

Ах да, используй паттерн ПовторКодВОтделМетод (прочитал в умной книжке).

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

так в том-то и дело, что повторяется все кроме строки double res = this.SolveCubic(1.4*alphaj, -(4.2*alphaj-1), 4.2*alphaj, -1-m); тут или хранить формулы в конфиге и писать какой-то парсер для них или не знаю что

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

так в том-то и дело, что повторяется все кроме строки double res = this.SolveCubic(1.4*alphaj, -(4.2*alphaj-1), 4.2*alphaj, -1-m); тут или хранить формулы в конфиге и писать какой-то парсер для них или не знаю что

А дык это ж у тебя метаданные о методе собираются, да? Пиши-пиши ручками, не выпендривайся.

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

хранить формулы в конфиге и писать какой-то парсер для них

Разумеется. Причем желательно парсить tex-овскую строку, которая затем as-is скопируется в отчет.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

Разумеется. Причем желательно парсить tex-овскую строку, которая затем as-is скопируется в отчет.

Променять простой чистый Java-код на какой-то матан? Ты потом это поддерживать будешь? Гнать ссаными тряпками таких вот гениев.

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

Променять простой чистый Java-код на какой-то матан?

Променять хардкод СНИП-овских простыней на интерпретатор православного tex-а.

Ты потом это поддерживать будешь?

Предпочтёшь из раза в раз объяснять заказчику, почему в отчете фигурирует одна формула, а вычисления опять выполнены по совсем другой?

ГПроменять простой чистый Java-код на какой-то матан? нать ссаными тряпками таких вот гениев.

«Среднестатистическое быдло прекрасно понимает, что матан ему не осилить.» Расслабься, твоё мнение насчёт гнать-негнать никому не интересно.

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

Променять хардкод СНИП-овских простыней на интерпретатор православного tex-а.

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

«Среднестатистическое быдло прекрасно понимает, что матан ему не осилить.» Расслабься, твоё мнение насчёт гнать-негнать никому не интересно.

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

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

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

А дублирование - это плохо. Это гарантирует, что дубли рано или поздно разъедутся.

А я и не должен быть умным. Таких, как я, большинство.

Всё верно. Нудной и монотонной работы всегда много, так что недоумкам всегда есть что поручить. А потом еще ополовинить премию за косяки, которые были сделаны из-за недостатка внимания. Жалеть вас смысла нет: один уволится - нанимаешь следующего, такого же долбоклюя.

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

И писать код ты обязан, рассчитывая на меня.

Код должен быть простым и понятным, никаких «перловых портянок», да. Но из этого вовсе не следует, что его сможет поддерживать каждый первый ПТУ-шник. http://failblog.org/2009/08/12/racism-fail/

----

Что касается проблемы ТС, но нужно нарыть готовую библиотеку для tex-овских формул. Ваша жабка ведь богата на библиотеки?

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

Ваша жабка ведь богата на библиотеки?

Мде. Тухлячок-с. http://stackoverflow.com/questions/9880179/java-or-scala-library-to-parse-lat...

Значит, нужно хранить формулы в каком-то другом формате, который с одной стороны автоматом парсится и eval-ится, а с другой - автоматом конвертируется в tex.

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

А дублирование - это плохо. Это гарантирует, что дубли рано или поздно разъедутся.

Это не дублирование, это служебный Java-код. Может еще объявления классов в дублирование запишешь? Все должно быть написано на тупом, чистом, понятном Java-коде. На крайний случай XML можно задействовать. Все остальное ненужный матан.

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

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

Ваша жабка ведь богата на библиотеки?

Так ты сам не из энтерпрайза? Че лезешь тогда? На маргинальщине своей можешь писать, как угодно, разрешаю.

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

Это не дублирование, это служебный Java-код.

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

Так ты сам не из энтерпрайза?

Ынтырпрайз не сводится к жабке. Сюрприз?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

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

Второе генерируется из первого.

Ынтырпрайз не сводится к жабке. Сюрприз?

Java и только Java. Ну еще Common Lisp для умников, но их можно не брать в расчет.

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

Второе генерируется из первого.

У ТС - не генерируется.

Java и только Java

Если сто раз повторить «сахар», то во рту станет сладко?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

У ТС - не генерируется.

У него лог в TeX генерируется. Но вопрос не об этом, а о том как сократить служебный Java-код, который он привел в качестве примера. Ответ: не надо выпендриваться и оставить, как есть.

Если сто раз повторить «сахар», то во рту станет сладко?

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

Про Common Lisp я уже сказал, энтерпрайз для умников, их не учитываем.

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

TeX-нотация неоднозначна и невычислима. Тут уж разве что mathml какой сгодится.

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

Вот именно. TeX из Java сделать элементарно. А обратное в общем случае вообще невозможно. Вот, что здесь написано: $a \cdot b$?

anonymous
()

Возьми вторую главу из СИКП'а. Там есть простенькая решалка дифференциальных уровнений. Если его чуть-чуть доделать, то получится годный вычислитель и преобразователь формул из sexp в TeX-нотацию. Правда я без понятия как это сделать на жабе.

ugoday ★★★★★
()

Как на счёт купить одну лицензию Woflram Mathematica и вызывать ее из джавы? API у них приличный. А сама математика и посчитает, и в ТеХ преобразует, и ребенку пеленки сменит.

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

Зависит от задачи. Математика - мощнейший инструмент, плюс к ней мы получаем интерактивную разработку. Но довольно таки высокая цена и проприетарность - это минус.

Если сами формулы слишком сложные, и требуют нетривиальных преобразований, то почему бы и Математика?

А за упоминание GiNaC спасибо. Возьму на заметку.

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

Я подозреваю, что в СНИПах зубодробильных формул быть не может, поэтому для задач автора достаточно написать парсер _очень_ ограниченного подмножества ТеХа.

ugoday ★★★★★
()

А, с другой стороны, к задаче можно подступиться и иначе. Есть такая штука как Sweave, которая реализует литературное программирование для R. Синхронизировать расчётные функции с описанными в ТеХе формулами придётся вручную, зато подставлять результаты расчётов в итоговый ТеХовский документ получится автоматом.

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

Копипастил мои высеры? Слабак. Лучше бы свое что придумал.

Буду совершенствоваться, Мастер.

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