Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2006.04.16;
Скачать: [xml.tar.bz2];

Вниз

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

 
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 и пр.



Страницы: 1 2 вся ветка

Форум: "Прочее";
Текущий архив: 2006.04.16;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.57 MB
Время: 0.135 c
15-1143486900
Dbnr
2006-03-27 23:15
2006.04.16
Пересечение прямоугольников!!


4-1138280826
Kolan
2006-01-26 16:07
2006.04.16
Помогите разобраться с небольшим участком код...


3-1140616606
Olle
2006-02-22 16:56
2006.04.16
Ошибка записи


2-1143722889
max1980
2006-03-30 16:48
2006.04.16
Нестандартные цвета компонентов


4-1138015760
Kremen
2006-01-23 14:29
2006.04.16
SendInput





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский