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