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