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