|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Serguei Miridonov 2:5020/400 25 Mar 2005 21:08:15
To : U.P.Galyuck
Subject : Re: Need GUI development tool (Kylix or something)
--------------------------------------------------------------------------------
U.P.Galyuck wrote:
> Если вы не знаете о коммутативности операций умножения,
Да все знают... Если, конечно, речь идёт о множестве комплексных
чисел. А то ведь по всякому бывает... ;-)
> Программисты обслуживают математиков, а не наоборот.
Далеко не всегда. Именно математики занимаются, например,
устойчивостью алгоритмов вычислений, или криптоанализом (сами знаете
для чего), или оптимизацией распараллеливания вычислений, и многим
другим.
Вы уж как-то совсем принижаете труд программиста, прямо как
чернорабочего какого-то на побегушках.
Заметьте, я сам программистом не являюсь, так что не интересы
"своего класса" я тут представляю. ;-)
> Hи в каком
> языке не может закладываться ограничение, просто из удобства реализации.
> Hаоборот, всегда говорится - что конкретная реализация чего-то возлагается
> на разработчиков трансляторов. А вот разработчик - хочет сделает это
> эффективнее, а хочет - сделает по дубовому. Именно поэтому трансляторы
> разные, и стоят по разному.
Вот тут я кардинально с Вами не согласен. Давайте по порядку, а то
спор этот уже затянулся...
1. Закон ассоциативности для операций класса сложения или умножения
в пространстве комплексных чисел работает только в теории, т.е. Вы
можете пользоваться им для аналитических, или - символьных
вычислений. Hикто с этим не спорит.
2. В компьютерах, по крайней мере в том типе ЭВМ, о котором тут идёт
речь, только очень _узкий_ класс чисел может быть представлен точно
- из-за ограниченной разрядности. Следовательно, и результаты
операций с этими числами будут представлены лишь приближённо.
3. Умножение или сложение в компьютере, если уж копать до конца -
это не арифметические операции, а множество _логических_. Они
реализованы как отдельные алгоритмы, поэтому говорить о том, что
если это умножение, то там должна быть ассоциативность просто нельзя.
4. Учитывая (2) и (3) можно сказать, результат вычислений с
несколькими операндами практически неизбежно будет зависеть от
порядка промежуточных вычислений. За примером даже не надо ходить в
сторону комплексных чисел, достаточно поскладывать группы чисел,
одни из которых много больше других.
5. Языки высокого уровня обычно могут использоваться на машинах с
разной архитектурой, в связи с этим желательно, чтобы алгоритмы
разработанные под решение, в некотором смысле, универсальных задач
(решение дифф. уравнений, интегрирования и многие другие) тоже были
портируемыми, т.е. результаты вычислений не сильно бы зависели от
архитектуры, а также - чтобы разработанные алгоритмы сохраняли
устойчивость при переходе с одной машины на другую. Кроме этого,
необходимо чтобы выполнение алгоритмов не сильно зависело и от
компилятора.
6. Комбинируя (4) и (5) можно придти к выводу, что порядок
вычислений должен как-то регламентироваться. И этот порядок задаётся
в стандарте языка, как в фортране, так и в C/C++.
>> Вообще-то то, что Вы предлагаете -- это воспользоваться
>>ассоциативностью операции умножения встроенных вещественных
>>типов. Коей ассоциативности _ПРОСТО_HЕТ_!
>
>
> Как это нет. Об этом написано в любом учебнике по арифметике.
См. пункт (3).
> Поясняю, что имеется в виду. Пусть требуется поделить два числа z=x/y.
> Если числа вещественные, то это делается в одну операцию. При комплексной
> реализации той же операции, числитель и знаменатель домножаются на
> комплексно сопряженное знаменателю, после чего происходит операци деления. С
> математической точки зрения делается z=x*y/y**2 (мы учитываем наличие
> нулевых мнимых частей). Ясно, что второй вариант потенциально опаснее с
> точки зрения переполнения, и если компилятор сумел избежать лишних
> вычислений, то он молодец. Отсюда и следует, что оптимизация выражений
> расширяет диапазон исходных данных.
Вопрос: а _обязан_ ли компилятор заниматься оптимизацией? Откуда ему
знать, будет ли нулевой мнимая часть чего-то во время выполнения?
Если так рассуждать, то Вы скоро вмените в обязанность компилятору
вызывать алгоритм сортировки чисел перед сложением.
> Да, а что, есть в стандарте запрет на оптимизацию выражений? Где это
> написано?
Hаписано про регламентированный порядок вычислений. Ссылку я
приводил в одном из моих предыдущих постингов, но Вы её проигнорировали.
Оптимизация же допускается, однако если это отступление от
стандарта, то это должно быть отражено в мануале на компилятор и
включаться явно: опцией, а ещё лучше - прагмой, потому, как в одной
части алгоритма это может быть приемлемо, а в другой - нет.
--- ifmail v.2.15dev5.3
* Origin: CICESE Research Center, Ensenada, Mexico (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
