Всем привет. В некоторых языках для возведения в степень используется оператор "^". Чем это вызвано — понятно, тяжело обеспечить написание символов в верхнем индексе, да и никому оно не надо. Оператор используется давно, и я, например, всегда считал, что он имеет те же свойства, что и минус или деление, то есть выражение a^b^c = (a^b)^c, по аналогии с a-b-c = (a-b)-c (оператор некомутативен, операции выполняются слева-направо). Но оказалось, что это зависит от языка, в некоторых порядок выполнения операций справа-налево. Так вот, вопрос: существует ли какой нибуть документ, регламентирующий это направление, помимо стандартов для конкретных языков(Basic, Maple, Python etc.). В конце концов, кто-то когда-то придумал так использовать этот оператор для возведения в степень. Каким было "каноническое" направление?

Здравствуйте, Mace, Вы писали:

M>Но оказалось, что это зависит от языка, в некоторых порядок выполнения операций справа-налево.
А разве не во всех?
В обычной математической записи принято, что 2^2^2 означает 2^(2^2), а не (2^2)^2.

Здравствуйте, mkizub, Вы писали:
M>А разве не во всех?
Нет, не во всех. Basic к примеру, или парсер Excel считает слева-направо. Maple вообще отказывается считать такие выражения без скобок — говорит, что они обязательны.
M>В обычной математической записи принято, что 2^2^2 означает 2^(2^2), а не (2^2)^2.
Кем принято? Должен же быть какой-нибуть стандарт =)

Здравствуйте, Mace, Вы писали:

M>Здравствуйте, mkizub, Вы писали:
M>>А разве не во всех?
M>Нет, не во всех. Basic к примеру, или парсер Excel считает слева-направо. Maple вообще отказывается считать такие выражения без скобок — говорит, что они обязательны.
M>>В обычной математической записи принято, что 2^2^2 означает 2^(2^2), а не (2^2)^2.
M>Кем принято? Должен же быть какой-нибуть стандарт =)

В физике все формулы так пишут.

M> Но оказалось, что это зависит от языка, в некоторых порядок выполнения операций справа-налево.

По поводу порядка вычислений для операций с равным приоритетом (из Википедии):

Приоритет операций в Си

Ниже приведены операции в порядке убывания приоритета. Операции, приведённые на одной строчке, имеют одинаковый приоритет. Операции, помеченные как R->L, исполняются справа налево.

() [] -> .
Унарные (R->L): ! ~ — * & sizeof (type) ++ --
Бинарные арифметические: * / %
Бинарные арифметические + —
Сдвиг: << >>
Сравнение: < <= > >=
Сравнение: == !=
Битовая: &
Битовая: ^
Битовая: |
Логическая: &&
Логическая: ||
Тернарная (R->L): ?:
Операции с присваиванием (R->L): = += -= *= /= &= |= ^= <<= >>=

Выходит, большинство операций выполняются слева направо. Проверять это ввиду их ассоциативности сложно, но можно:

  f = 2 + 1E100 - 1E100
  f = 2 + (1E100 - 1E100)

В первом случае должен получиться 0, во втором — 2.


А вот ещё интересная статья:
http://en.wikipedia.org/wiki/Order_of_operations

В частности, в разделе Calculators приведён пример граблей со степенями в разных моделях калькуляторов TI

Mace пишет:
> то есть выражение a^b^c = (a^b)^c, по
> аналогии с a-b-c = (a-b)-c
Если a^b^c^d = ((a^b)^c)^d, то это как–то глупо получается. Написали
кучу возведений в степень, а получили всего лишь возведение в
произведение этих степеней. Возведение в произведение можно и так написать.

OCT>Если a^b^c^d = ((a^b)^c)^d, то это как–то глупо получается. Написали
OCT>кучу возведений в степень, а получили всего лишь возведение в
OCT>произведение этих степеней.

Вот-вот, то же самое написано про эту операцию в Python тут:
http://en.wikipedia.org/wiki/Operator_associativity

Здравствуйте, Mace, Вы писали:

M>Каким было "каноническое" направление?

В математике нет символа возведения в степень, там просто степень пишется повыше:

   2
  3
-2

Если ввести символ, то становится очевидно, что возведение в степень должно быть правоассоциативно и иметь больший приоритет, чем унарный минус:

-2^3^2 это -(2^(3^2))

Здравствуйте, Кодёнок, Вы писали:

Кё>Если ввести символ, то становится очевидно, что возведение в степень должно быть правоассоциативно и иметь больший приоритет, чем унарный минус:

Кё>-2^3^2 это -(2^(3^2))

Совершенно согласен. И еще, операция возведения в степень — это такая редкая вычислительная процедура, что существует только в Фортране и Бейсике. Ну а раз уж она существует, то она должна быть согласована с традиционными записями, а иначе какой смысл выделять возведение в степень в качестве отдельного символа?

McSeem2 пишет:
> Совершенно согласен. И еще, операция возведения в степень — это такая
> редкая вычислительная процедура, что существует только в Фортране и
> Бейсике.
И в Аде

Здравствуйте, McSeem2, Вы писали:

MS>Совершенно согласен. И еще, операция возведения в степень — это такая редкая вычислительная процедура, что существует только в Фортране и Бейсике. Ну а раз уж она существует, то она должна быть согласована с традиционными записями, а иначе какой смысл выделять возведение в степень в качестве отдельного символа?

В Хаскелле даже три

(**) :: (Floating a) => a -> a -> a
(^)  :: (Integral b, Num a) => a -> b -> a
(^^) :: (Fractional a, Integral b) => a -> b -> a

Но все три правоассоциотивны и имеют приоритет выше умножение, как и положено:

infixr 8  **
infixr 8 ^, ^^

Здравствуйте, deniok, Вы писали:

D>В Хаскелле даже три

Кстати, где-нить есть обоснование для трёх операций возведения в степень, для разных операций деления (div и /), ну и по подобным таким же делам? Это всё было обдуманно и взвешенно или так случайно получилось?

Здравствуйте, geniepro, Вы писали:

G>Здравствуйте, deniok, Вы писали:

D>>В Хаскелле даже три

G>Кстати, где-нить есть обоснование для трёх операций возведения в степень, для разных операций деления (div и /), ну и по подобным таким же делам? Это всё было обдуманно и взвешенно или так случайно получилось?

Это вполне естественно — код разный для плавающей точки, для натуральной степени и для целой степени (требует наличия деления для отрицательных степеней). Ну и из всей иерархии классов типов чисел более-менее естественно получается. В Gentle Intro 10 глава.

Здравствуйте, deniok, Вы писали:

D>Ну и из всей иерархии классов типов чисел более-менее естественно получается. В Gentle Intro 10 глава.

Вот чего реально не хватает, причем во всех языках высокого уровня, так это операции MulDiv в целых числах. Причем, в ассемблере это очень естественно, а вот в языках — просто нету. Ну на всякий случай поясню — промежуточный результат должен иметь вдвое большую разрядность, то есть в точности как это происходит при выполнении IMUL IDIV.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, deniok, Вы писали:

D>>Ну и из всей иерархии классов типов чисел более-менее естественно получается. В Gentle Intro 10 глава.

MS>Вот чего реально не хватает, причем во всех языках высокого уровня, так это операции MulDiv в целых числах. Причем, в ассемблере это очень естественно, а вот в языках — просто нету. Ну на всякий случай поясню — промежуточный результат должен иметь вдвое большую разрядность, то есть в точности как это происходит при выполнении IMUL IDIV.

Я просто не в курсе — это повышает эффективность по сравнению с естественным самоограничением на перемножаемые целые: не превышать 2 в степени половина_разрядности_платформы?

Здравствуйте, deniok, Вы писали:
D>Я просто не в курсе — это повышает эффективность по сравнению с естественным самоограничением на перемножаемые целые: не превышать 2 в степени половина_разрядности_платформы?
Конечно, потому что этого ограничения в IMUL/IDIV нет.

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, deniok, Вы писали:

D>>Ну и из всей иерархии классов типов чисел более-менее естественно получается. В Gentle Intro 10 глава.

MS>Вот чего реально не хватает, причем во всех языках высокого уровня, так это операции MulDiv в целых числах. Причем, в ассемблере это очень естественно, а вот в языках — просто нету. Ну на всякий случай поясню — промежуточный результат должен иметь вдвое большую разрядность, то есть в точности как это происходит при выполнении IMUL IDIV.
Тогда ещё и DivMod...