|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : U.P.Galyuck 2:5020/400 24 Mar 2005 19:43:21
To : Ilya Anfimov
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
> > Разумеется, я этого не думаю. Конечно, g77 и gcc хреновые
компиляторы.
> > Именно поэтому профессиональные программисты во всем мире используют
> > коммерческие компиляторы типа pg90. Hо именно вы предложили
использовать
>
> А давайте не будем кивать на профессиональных программистов во
> всём мире? Тем более, что любое сравнение того, что они в среднем
> используют, будет на в Вашу пользу?
Извините, имелось в виду "профессиональных программистов на Фортране". У
вас есть другие сведения? Так поделитесь ими. Мы немедленно закупим
предложенный вами наиболее эффективный компилятор (то же самое про
компилятор С). А я вам в ответ расскажу грустную историю, про то, как из-за
ограничения COCOM нам так и не продали компиляторы от Portland Group,
впрочем, левый у нас есть. Это я к тому, что про компиляторы я не
понаслышке.
> > для арифметических операций с комплексными числами GNU C. Именно поэтому
я
> > его и исследовал.
>
> Я предложил использовать C. Можно, в частности, GNU.
Слов про "в частности, GNU" не было. Впрочем, я понимаю, этот инструмент
есть у всех, поэтому он и был упомянут.
> Возможность реализовать комплексную арифметику лучше, чем в GNU C
> Вами пока что не показана.
Да, не показана Я только предполагаю, что при оперировании встроенными
типами данных, каким, без сомнения, является тип complex в Фортране, можно
добиться более глубокой оптимизации выражений, чем в языках, где этот тип
является заплаткой. Далее, основываясь на том, что такого рода оптимизации,
основывающиеся на коммутативности некоторых смешанных операций
вещественное-комплексное, уже раньше были реализованы, я делаю смелое
утверждение, что такого рода оптимизация компиляторами используется и в
настоящее время. Заметим, я ничего не утверждаю, просто поясняю, как такой
дубовый язык, как Фортран, мог бы уделать в плане эффективности получаемого
кода современные навороченные языки, не ориентированные на научные
исследования. А быстрее всего таки уделал.
> Это ничего, что в IEEE floating point arithmetics
> (a*b)*c вообще говоря не равно a*(b*c)?
В теоретическом плане это очень серьезное возражение. Особенно, если
учесть, что программист обычно пишет так, как написано на листочке с
формулой, которая подразумевала ассоциативность/коммутативность операции
умножения. А вот в практическом плане если перестановка сомножителей влияет
на результат, значит надо менять алгоритм. Hельзя работать на предельных
точностях. И, как было ранее сказано, никто не отвергал скобки в выражениях,
да вот только для эффективности оптимизации их лучше не ставить.
> Вы не провели _никакого_ сравнения фортрана и C.
>
> Для профессиональных спорщиков: если скажете, что сравнение
> подразумевало отсутствие в фортране тех вещей, в которых Вы
> обвиняли C, то я там показал, что в фортране они присутствуют в
> том же объёме.
Пожалуйста, еще раз и помедленнее, особенно о том, что в Фортране
присутствует в том же объеме. Я который раз повторяю: я ни в коем случае не
доказываю, что Фортран эффективнее С в научных расчетах, я только обращаю
внимание на то, что это, действительно, может иметь место как раз в силу
особенностей этого языка. И поэтому есть смысл продолжать на нем работать.
Галюк Юрий
--- ifmail v.2.15dev5.3
* Origin: St.Petersburg University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
