Какой язык лучше для моделирования?

← →
Юрий Зотов © (2006-03-26 13:28) [40]

> isasa © (26.03.06 13:17) [37]

1. Естественно, все это можно реализовать и на Delphi и вообще на чем угодно. Но вовсе не "легко". Для начала придется писать и тестировать (или искать готовый, причем такой, которому можно доверять) пакет математики - что это за труд, Вы понимаете. В то время, как подобные пакеты для Фортрана уже существуют и вполне доступны. Так что же будет легче?

2. Современные Фортраны для Windows точно так же позволяют интегрироваться с Word, Excel и пр.

← →
boriskb © (2006-03-26 13:28) [41]

Кстати.
Можно много спорить/рассуждать по поводу
"Что такое язык программирования?"

← →
Юрий Зотов © (2006-03-26 13:32) [42]

> isasa © (26.03.06 13:22) [38]

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

← →
isasa © (2006-03-26 13:33) [43]

Юрий Зотов © (26.03.06 13:28) [40]
Для начала придется писать и тестировать (или искать готовый, причем такой, которому можно доверять) пакет математики
Вот ключевая фраза.
А вообще, если долго этим заниматься, лучше потихоньку написать и оттестировать свой. Чужой - это всегда, в определенной степени "черный ящик".

← →
Sergey Masloff (2006-03-26 13:44) [44]

isasa © (26.03.06 13:33) [43]
Насколько долго.И что значит написать?
Взять готовый код на фортране и переписать на другом языке? Реализуемо но время... И возникает вопрос - зачем.

Взять описание алгоритма и написать свой код? Для достаточно сложных алгоритмов задача не такая простая. Если еще и опыт программирования невелик - это уже очень долго.

Придумать самому алгоритм, математически доказать его корректность, написать свою реализацию - для абсолютного большинства посетителей форума срок реализации - НИКОГДА.

Такое мое скромное ИМХО.
Кстати
1) фортран синтаксически действительно несложный язык.
2) интел регулярно совершенствует свой компилятор фортрановский, и разница в производительности там не 5%
3) библиотеки фортрана уже достаточно упорядочены и при поиске нужного не придется перелопачивать тысячи вариантов
4) фортран давным-давно поддерживает COM, DCOM и иже с ними

← →
isasa © (2006-03-26 13:47) [45]

Юрий Зотов © (26.03.06 13:32) [42]
Согласен. Re, Bi, Fo, Nu - не для слабонервных. :)

Все пошел голосовать. Не хочется, но надо.:)

← →
Eraser © (2006-03-26 14:21) [46]

> u-12 (25.03.06 21:26)

А зачем моделировать кристалл?
Ответ на этот вопрос даст ответ на выбор компилятора.
Может промоделировать кристалл нужно в учебных целях, именно для изучения тех самых сложных алгоритмов, которые в фортрановских библиотеках, тогда те самые библиотеки просто нельзя использовать )
Если же чисто в научных целях изучения св-ств кристалл, тогда то что удобнее, наверное фортран раз его тут так расхвалили.

← →
Юрий Зотов © (2006-03-26 22:52) [47]

> Sergey Masloff (26.03.06 13:44) [44]

> Взять готовый код на фортране и переписать на другом языке?

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

И тогда придется очень долго и очень нудно тестировать, вылавливать и шлифовать глюки (особенно, если они окажутся еще и "плавающими", что в численной математике скорее правило, чем исключение). В общем, делать ту же самую работу, на которую Фортран-сообщество, в основном, и потратило уже те самые полвека.

← →
TUser © (2006-03-27 09:39) [48]

> isasa © (25.03.06 22:46) [16]

В сложных вычислениях принято избегать использования типа double.

> Юрий Зотов © (26.03.06 11:56) [26]

Я все, конечно, понимаю. Но только последние лет 20 вычислительные задачи успешно пишутся на С. В последнее время - на джаве. Некоторые даже Перл используют, зачем - не в курсе. Некоторые вне себя от Питона, почему - не в курсе. Главные аргумент С-вычислителей - переносимости. Ansi C программу они компилируют на любую платформу, т.е. могут выпонлять свои программы на Солярисовых кластерах. Превращая несколько дней вычислений в несколько часов.

Зы. Я в курсе, что есть gnu-fortran. gnu-Pascal тоже есть.

← →
КаПиБаРа © (2006-03-27 10:20) [49]

Когда решал вычислительные задачки в дипломе, тестировал пример на фортране и на С. С на 30% быстрее считал. Реализовал все равно на фортране. 10 секунд процесса обсчитывалось за 40 минут.

← →
Юрий Зотов © (2006-03-27 10:41) [50]

TUser © (27.03.06 09:39) [48]

> Главные аргумент С-вычислителей - переносимости. Ansi C программу они
> компилируют на любую платформу, т.е. могут выпонлять свои программы
> на Солярисовых кластерах. Превращая несколько дней вычислений в
> несколько часов.

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

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

← →
isasa © (2006-03-27 11:59) [51]

TUser © (27.03.06 09:39) [48]
В сложных вычислениях принято избегать использования типа double.

!!!!
Допустим. А какой тип использовать?

← →
TUser © (2006-03-27 13:05) [52]

int

← →
isasa © (2006-03-27 13:12) [53]

Вот те раз! А если у меня вещественные числа.
Да та-же длина окружности с радиусом R ?

← →
TUser © (2006-03-27 13:29) [54]

> А если у меня вещественные числа.

Умножаем их на коэффициент. Работаем с целыми, это быстрее.

← →
isasa © (2006-03-27 13:36) [55]

Быстрее то оно быстрее, а вот достоверность и точность результата? Как определить этот коэффициент?
В этом случае, я предпочитаю проверенный стандарт IEEE. :)

← →
TUser © (2006-03-27 13:38) [56]

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

← →
isasa © (2006-03-27 13:56) [57]

:)
Действительно. Ну его нафиг этот FPU.
Имеем
Pn(Pm(Ci,y),x)=0
где
Pn, Pm - полиномы n,m-й степени (n,m=~7..10)
Ci - коэффициенты, заданные с точностью 10 знаков (0.ххххххххххExx),
Необходимо определить корни х, при каждом заданном у.

Как посчитать этот коэффициент?
И что делать с числами больше 0.4294967295 ?

← →
TUser © (2006-03-27 14:38) [58]

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

← →
Jeer © (2006-03-27 14:43) [59]

TUser © (27.03.06 14:38) [58]

В песочницу:)

← →
isasa © (2006-03-27 14:54) [60]

TUser © (27.03.06 14:38) [58]
Спасает, даже позволяет выходить из цикла с относительной погрешностью 1E-9 долей единицы.

← →
TUser © (2006-03-27 14:56) [61]

> В песочницу:)

Да хоть куда. Сказанное от этого не становится неправдой.

И все-таки она вертится!
(с)

← →
Jeer © (2006-03-27 15:01) [62]

TUser © (27.03.06 14:56) [61]

"Нужна ли программисту математика ?"

Оказывается - нет, т.к. подмножество натуральных чисел - целые int (всего 32 разряда), позволяют решать "серьезные" вычислительные задачи, перед которыми пасуют даже double :))

Или Вы о сетке длиной в N-разрядов ?
Это частный случай, если бы все шли только таким путем, то считать на счетах было бы быстрее:))

← →
isasa © (2006-03-27 15:23) [63]

TUser © (27.03.06 14:56) [61]
Рекомендую почитать и не изобретать велосипеда (со стандартом IEEE 754, хуже, описание не нашел).
http://www.klgtu.ru/ru/students/literature/inf_asu/560.html
http://dims.karelia.ru/x86/env_5.shtml.

А FPU использовать по прямому назначению, а не как второй процессор в режиме гипертрейдинга. :)

← →
u-12 (2006-03-28 00:35) [64]

МАМА_МАЙА_ДАРАХАЙА...))
Ну вас всех.. напишу на Delphi без VCL - меньше мороки..
По поводу фортрана...
Юрий Зотов © (25.03.06 23:18) [22]
Я не имел в виду, что он старый.. Сейчас есть Fortran 8.0 или еще что-то более новое. За сутки можно и с Java разобраться, было бы желание... Всегда все абсолютно незнакомое тяжело дается (по крайней мере, так кажется).
3 суток - это недостаток самого алгоритма (кристалл 100х100х100, атомы рандомом выбираются и потом считаются коеффициенты для всех атомов по несколько раз). К сожалению, другого алгоритма нет.
И если программа вместо 72 часов будет работать 70 часов, то это меня не спасет..;0

Так что всем спасибо..)

← →
Jeer © (2006-03-28 10:22) [65]

u-12 (28.03.06 00:35) [64]

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

← →
Юрий Зотов © (2006-03-28 12:01) [66]

> u-12 (28.03.06 00:35) [64]
> Я не имел в виду, что он старый..

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

> Юрий Зотов © (28.03.06 12:01) [66]

извините, что офтоп, Вы не напомните как Вы писали объявление массива безразмерного в паскале?
Там что-то типа типа было, а потом переменная этого типа..
Короче, память не юзалась. (помнится, еще кто-то такое у студента, которому была оказана эта помощь) забраковал - якобы память сразу выделяется)

Vlad Oshin © (28.03.06 12:27) [67]

извините, но это есть в любой справке по Delphi, начиная с..
Динамические массивы.

type
TDEar = array of extended;

var
arA: array of double;
arB: array of array of double;
arC: TDEar;

> Jeer © (28.03.06 12:54) [68]

Извините, но меня интересует именно паскаль
Проверить прямо сейчас Ваше решение нет возможности, проверю потом
Заранее спасибо

а что, разве математически библиотеки с фортрана на С давным-давно не переписаны ?

Игорь Шевченко © (28.03.06 13:11) [70]

Один из кладезей премудрости достигаем - www.srcc.msu.su
Но Delphi и вычисления - это где-то рядом, но не около.

> Vlad Oshin © (28.03.06 12:27) [67]

Что-то типа этого:
type TDataType = ...; { Хоть Integer, хоть что угодно еще } TDataArray: array[1..(65532 div SizeOf(TDataType))] of TDataType; { Массив максимального для DOS размера. Память еще не выделяется, о чем преподаватель Паскаля был просто обязан знать. } procedure Proc(N: word; var A: TDataArray); { N - реальное кол-во элементов в массиве A. Сам массив здесь объявлен, как массив максимально возможного размера, благодаря чему процедура получается универсальной и может быть использована в любой программе без малейшего изменения ее кода. Память под массив здесь тоже еще не выделяется, а сам массив передается по ссылке через стек, отъедая в нем всего 4 байта (2 байта - смещение, 2 байта - сегмент). Этот маленький трюк не только дает возможность сделать процедуру универсальной, еще он позволяет писать в ней простой, удобный и легко читаемый код работы с массивом, без всяких указателей и прочей чехарды. Например, такой: } var i: word; begin { Proc } for i := 1 to N do A[i] := 0 end; { Proc } { Используется все это так: } const Size = 100; { Реальный размер массива } var Arr: array[1..Size] of TDataType; { Реальный массив. Под него компилятор выделит память размером Size * SizeOf(TDataType). } begin ... Proc(Size, Arr); { Передаем процедуре реальные данные. } ... end.

не, что-то не то
как то не так было, вроде...
или путаю

все-таки, наверное, надо со списками делать,
смущает var вполне определенный

> Юрий Зотов © (28.03.06 13:54) [72]

Это видимо для версий Паскаля ниже 7?
Ибо в 7 уже были Low,High, и получение процедурой открытого массива.

> Юрий Зотов © (28.03.06 13:54) [72]

А в какой версии Паскаля это работало? Здесь же типы формального и фактического параметров не совпадают. А для var-параметров это — обязательное условие.

Я решал аналогичную проблему через передачу массива как нетипизированного параметра. С последующим приведением его внутри подпрограммы к типу-массиву.

> begin...end © (29.03.06 14:20) [76]

У меня это работало в TP5.5 (я вообще других TP не юзал, начал "паскалить" с 5.5, а когда приперла нехватка памяти (и даже оверлеи уже не спасали), сразу перескочил на Delphi).

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

Какой язык лучше для моделирования? Найти похожие ветки