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

← →
u-12 (2006-03-25 21:26) [0]

Ave...
Тут задача такая: промоделлировать кристалл... Не подскажите, какрй компилятор для этого лучше..
Я знаю Delphi/Pascal, немного в С разбираюсь...
Нужно, чтобы сама программа как можно меньше ресурсов ела, ибо сами вычисления проводятся по несколько суток непрерывной работы - т.е. красивые виндозные оболочки не нужны, можно обойтись и консольным досовским окном. так что посоветуете?
Torba Pacsal 7 не подходит - там нельзя задавать большие массивы (у меня 100х100х100).
Буду пробовать Turo C++...

Фортран даже и не предлагать - не собираюсь я разбираться в этом древнем санскрите, каким бы он хорошим для мат. расчетов не был.
Есть ли какие-то новые (а главное, наиболее подходящиее для мат. расчетов) компиляции Паскаля или С под дос?.. Что посоветуете?..

← →
Mozart © (2006-03-25 21:36) [1]

← →
u-12 (2006-03-25 21:38) [2]

> С

А какая модификация?
Turbo C 3.11 (кстати, где его скачать можно, а то не могу найи никак)? Или может, есть что-то с более удобным виндозным редактором?...

← →
Sergey Masloff (2006-03-25 21:39) [3]

все же фортран. Для него есть новейшие компиляторы в том числе от интела - для математических расчетов быстрее всего.
А почему под дос? Там столько приседаний нужно чтобы хоть адресацию сделать для больоших данных... Если пока только "Я знаю Delphi/Pascal, немного в С разбираюсь..." то будут проблемы.

← →
Mozart © (2006-03-25 21:42) [4]

u-12 (25.03.06 21:38) [2]
А какая модификация?
просто C :)

← →
u-12 (2006-03-25 21:44) [5]

> Если пока только "Я знаю Delphi/Pascal, немного в С разбираюсь.
> .." то будут проблемы.

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

← →
u-12 (2006-03-25 21:46) [6]

> просто C :)

)) я имел в виду, чтобы с удобным редактором..

← →
TUser © (2006-03-25 21:48) [7]

FreePascal
Ansi C

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

Также подумать о параллельных вычислениях, если соотв. техника доступна.

← →
u-12 (2006-03-25 21:52) [8]

> TUser ©

Спс.
В данной задаче особые библиотеки и не нужны...

← →
Mozart © (2006-03-25 22:05) [9]

u-12 (25.03.06 21:46) [6]
> просто C :)
)) я имел в виду, чтобы с удобным редактором..

нельзя сравнивать С и С++

← →
u-12 (2006-03-25 22:12) [10]

>
> нельзя сравнивать С и С++

не буду

← →
isasa © (2006-03-25 22:31) [11]

Не забываем о поддержке сопроцессора FPU, команд >x386, иначе на простоте проиграем в производительности.

← →
DiamondShark © (2006-03-25 22:33) [12]

> В данной задаче особые библиотеки и не нужны...

Тогда пиши на том, что знаешь. В Дельфи без использования VCL получаются довольно компактные программы. Рассматривай его просто как 32-битный Паскаль.

← →
u-12 (2006-03-25 22:34) [13]

а на человеческом языке можно?..

← →
u-12 (2006-03-25 22:37) [14]

пред. сообщение относилось к

> isasa ©

← →
u-12 (2006-03-25 22:39) [15]

> DiamondShark ©

т.е. {$apptype console}?

← →
isasa © (2006-03-25 22:46) [16]

Если это ко мне, то ...
Вычислительнные задачи очень неплохо пишутся на Delphi. Проверено. Код можно сделать компактным, если подходить к этому вопросу без фанатизма.
Для сложной арифметики, удобнее использовать, все таки Delphi, чем C, из-за однозначности выражений.
Например, в С можно нарваться на потерю точности

double x,y;

y = x/3+2; // -> y = x/3.0+2.0;

а Дельфи все сделает правильно. Если арифметики много, следить за этим, утомлчет

← →
isasa © (2006-03-25 22:51) [17]

Да, по поводу генерируемого кода, достаточно посмотреть опции компилятора в том же Делфи.
А в "древних" компиляторах, по умолчанию предполагалось, что сопроцессора нет, его команды эмулировались, естественно производительность ... + разрядность 16 бит.

← →
DiamondShark © (2006-03-25 22:58) [18]

> u-12 (25.03.06 22:39) [15]

Это как раз самый малозначимый момент :)

Есть максима: самый лучший язык -- это тот, который лучше всего знаешь.
Если лучше всего знаком Дельфи/Паскаль, то и писать надо на нём. Чего ж проще?
Компилятор у дельфи хороший, сам язык тоже, тем более -- знакомый.
Зачем мучится выбором? Лучше это время потратить на программирование ;)

А если чем-то смущают всякие виндознусти и красивости -- плюньте. Вашей числодробилке они абсолютно ничем не помешают.
;)

← →
марсианин © (2006-03-25 23:10) [19]

> double x,y;
>
> y = x/3+2; // -> y = x/3.0+2.0;

именно в этом примере нет потери точности,
double/int = double
double + int = double

> Если арифметики много, следить за этим, утомлчет

единственная проблема - возможность неявного преобразования double->int
но любой порядочный компилятор на это дает warning

← →
марсианин © (2006-03-25 23:10) [20]

сорри за оффтоп)

← →
DiamondShark © (2006-03-25 23:11) [21]

> но любой порядочный компилятор на это дает warning

Это НЕ порядочный. Порядочный должен давать ошибку.

← →
Юрий Зотов © (2006-03-25 23:18) [22]

> сами вычисления проводятся по несколько суток непрерывной работы

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

> Что посоветуете?..

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

Но после второй цитаты не советую уже ничего. Поскольку советовать уже нЕчего.

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

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

← →
DiamondShark © (2006-03-26 10:29) [23]

А с какого это перепугу фортран -- лучшее средство?
Ссылку на миллион лемингов не предлагать.

← →
Sergey Masloff (2006-03-26 11:07) [24]

DiamondShark © (26.03.06 10:29) [23]
С того, видимо, что для него написана масса экстремально оптимизированых библиотек. И еще - кто нибудь не то что видел а и просто слышал о глюке в фортрановской библиотеке?

← →
KSergey © (2006-03-26 11:53) [25]

> u-12 (25.03.06 21:44) [5]
> Я написал на паскале, теперь нужно увеличить объем данных
> - перепишу на С...

Каким образом это позволит увеличить "объем данных"?

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

> DiamondShark © (26.03.06 10:29) [23]

Предлагается написать на Delphi/Паскале программу, решающую, например, задачу теплообмена или гидродинамики, а потом сообщить:
а). сколько времени было затрачено на ее разработку и отладку;
б). какова скорострельность программы.

Это и будет ответом на Ваш вопрос.

> Sergey Masloff (26.03.06 11:07) [24]

> для него написана масса экстремально оптимизированых библиотек.

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

> кто нибудь не то что видел а и просто слышал о глюке в фортрановской
> библиотеке?

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

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

← →
DiamondShark © (2006-03-26 12:27) [27]

> Sergey Masloff (26.03.06 11:07) [24]

Что мешает использовать готовые библиотеки с любым другим языком?

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

> Предлагается написать на Delphi/Паскале программу

Я так понял, Вы предлагаете мне за Вас доказать Ваше утверждение?

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

Любой компилятор фортрана? Сильное утверждение... Доказать бы.

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

А при чём здесь язык реализации?
Это говорит только о качестве специалистов и о затратах на тестирование.

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

← →
Kerk © (2006-03-26 12:29) [28]

Юрий Зотов © (26.03.06 11:56) [26]
а). сколько времени было затрачено на ее разработку и отладку;

Может и меньше, чем на изучение фортрана и его библиотек.

← →
DiamondShark © (2006-03-26 12:30) [29]

> И еще - кто нибудь не то что видел а и просто слышал о глюке
> в фортрановской библиотеке?

Мой сосед Вася написал фортрановскую библиотеку. Она один сплошной глюк.

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

← →
grisme © (2006-03-26 12:30) [30]

а почему нельзя на языке Ассемблера, используя сопроцессор и пр.мат.примочки?:)

← →
isasa © (2006-03-26 12:37) [31]

Юрий Зотов © (26.03.06 11:56) [26]
Предлагается написать на Delphi/Паскале программу, решающую, например, задачу теплообмена или гидродинамики, а потом сообщить:
:)
Легко.
Разница (по объему полученного кода, быстродействию) - ~+-5%, и, скорее всего, связана с особенностями построения исходного кода.

grisme © (26.03.06 12:30) [30]
а почему нельзя на языке Ассемблера, используя сопроцессор и пр.мат.примочки?:)

Можно, но при условии, что мазохизм надо поставить как самоцель. :)
В этом случае, уже важна не сама задача, а процесс ее реализации.

← →
isasa © (2006-03-26 12:40) [32]

isasa © (26.03.06 12:37) [31]
Разница ...
Имелось ввиду компоновка в обычную dll(не COM)

← →
grisme © (2006-03-26 12:45) [33]

> Можно, но при условии, что мазохизм надо поставить как самоцель.
> :)

Лучше однажды потратить время и силы на написание нечто универсального, быстрого(и не забыть выложить с сырцами :))), чтоб потом, на будущее, иметь быстрое средство...:)
Ну а если в будующем ничего не планируется, то....:)

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

> DiamondShark © (26.03.06 12:27) [27]

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

2. Язык реализации здесь при том, что:
а). Библиотека - это не обязательно DLL или объектный модуль. Иногда они бывают доступны только в исходниках.
б). Они писались на Фортране и подерживают его соглашения о вызове.

3. > хотя бы по одной особенности
Сечения массивов, встроенные векторные операции и комплексная арифметика...

← →
Sergey Masloff (2006-03-26 12:50) [35]

DiamondShark © (26.03.06 12:27) [27]
>Что мешает использовать готовые библиотеки с любым другим языком?
Их отсутствие и/или отсутствие данных о их стабильности.

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

> isasa © (26.03.06 12:37) [31]

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

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

> grisme © (26.03.06 12:45) [33]

> Лучше однажды потратить время и силы на написание нечто
> универсального, быстрого

Можно. А можно и не тратить, а использовать полувековой (и капитально оттестированный) результат труда других людей. К тому же, профессионалов.

← →
isasa © (2006-03-26 13:17) [37]

Легко, имелось ввиду не сама задача, а возможность ее реализации на Дельфи(кстати с той же интеграцией с другими приложениями, вплоть до Офиса(Word, Excel))

Для илюстрации уровня решаемых задач, одна из последних разработок - COM/DCOM сервер по документу:
"Release on the IAPWS Formulation 1995 for the Thermodynamic Properties of Ordinary Water Substance for General and Scientific Use", International Association for the Properties of Water and Steam, 1996. Executive Secretary R.B. Dooley, Electric Power Research Institute, Palo Alto, CA 94304, USA.

← →
isasa © (2006-03-26 13:22) [38]

А по поводу пластин ... :)
Условия не все. Нет основного.
Теплообмен за счет свободной конвекции или вынужденой?

← →
boriskb © (2006-03-26 13:24) [39]

DiamondShark © (26.03.06 12:27) [27]
А при чём здесь язык реализации?

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

А синтаксис конечно на эффективномть решения если и влияет, то не много.

← →
Юрий Зотов © (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]

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

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

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

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

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

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

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

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

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

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

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

TUser © (27.03.06 14:56) [61]

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

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

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

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

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

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

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

> 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.

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