В прикрепленном файле пример где различные формулы дают различжые результаты но печатаются одинаково. Если сумма возвышается в степень, тогда необходима скобка чтобы выражение было однозначное.

---

Wrote

Wrote

Я совершенно согласен, что применённая запись формулы была не самой удачной. Мне следовало бы не лениться и не торопиться. Однако:
1. Формула была введена так, чтобы можно было просмотреть её "исходный код" (и топикстартер продемонстрировал, что он может это сделать, когда процитировал формулу в своём ответе).
2. Несмотря на неочевидность, здесь нет нарушения требований синтаксиса математики. А при вводе всё достаточно очевидно - программа подчёркивает выражение, над которым производятся действия.

Возражаюсь. Не знаю более опасного нарушения требований синтаксиса математики чем неоднозначность. Ведь это вызывает неочевидные ошибки. Если однозначность только получается с помощю исходного кода или контекстного меню (как в другом серьёзном случая неоднозначности: оптимизация численная/символьная) - тогда SMath теряет смысль. Кому не хочется прямо видеть что и как вычисляется, тому Excel.

Если SMath не стремился к тому что любой лист доходчивый и однозначный и для не-SMathчиков (об очевидности уже не речь идет), я больще не мог бы его рекомендовать студентам. Дай бог (или Андрей) что не зря работа над учебником... Иначе пришлось бы стартовать проект для строения интерфейса в виде Mathcad/SMath для Maxima.

Меня не пугают недостатки нынешнего уровня SMath (наоборот, считаюсь ценительем), а что может быть ожидание однозначного формата считается вопросом вкуса.

(Пусть дискуссия идёт здесь, в топике, специально созданном для этой проблемы)

Я с Вами согласен. И в качестве примера, не вызывающего возражений, приведу возведение в степень: когда в SMath видим выражение

[MATH]a^c/b[/MATH]
не возникает сомнений, что именно возведено в степень: в данном случае числитель. В случае возведения всей дроби в степень скобки будут добавлены автоматически:

[MATH]{a/b}^c[/MATH]
Но всё же просто заставить программу городить скобки по любому поводу было бы тоже неправильно. Возьмём суммирование. Аналогично предыдущему примеру, применим эту операцию к дроби:

[MATH]sum(a/b;a;1;n)[/MATH]
Здесь всё прекрасно видно и без скобок; лишние скобки в этом случае будут только загромождать выражение в ущерб ясности. А со сложением не всё так гладко:

[MATH]sum(a+b;a;1;n)[/MATH] vs [MATH]sum(a;a;1;n)+b[/MATH]
В первом случае a+b под знаком суммы, во втором результат суммирования a сложен с b. А ведь вариант записи интегралов, сумм и произведений сложных подынтегральных выражений без скобок весьма распространён и общепринят. И формализовать такие неоднозначности можно разве что "матрицей скобок", где для каждой пары операций будет проставлено, требуются скобки или нет. И то всем не угодишь... Может быть, лучше требовать аккуратности от автора формулы? (Камень в мой огород.) Хотя это не выход, заранее соглашусь.

Wrote

А со сложением не всё так гладко:

[MATH]sum(a+b;a;1;n)[/MATH] vs [MATH]sum(a;a;1;n)+b[/MATH]
В первом случае a+b под знаком суммы, во втором результат суммирования a сложен с b. А ведь вариант записи интегралов, сумм и произведений сложных подынтегральных выражений без скобок весьма распространён и общепринят. И формализовать такие неоднозначности можно разве что "матрицей скобок", где для каждой пары операций будет проставлено, требуются скобки или нет. И то всем не угодишь... Может быть, лучше требовать аккуратности от автора формулы?

Матрица скобок действительно может быть хорошое решение. Пока вероятно надо согласиться на то, как её запольнять. Пусть различаем где

• обязательo
  
• можно
  
• нельзя

ставить скобки чтобы намерение исходного кода была правилно изображено. Это определяет свободу автора

С исходным кодом sum(((R.2/j)^{-1}),j,1,m)^{-1} представление

[MATH lang=eng]sum(((R.2/j)^{-1}),j,1,m)^{-1}[/MATH]

не только неоднозначное а просто неправилное. Внешный степень по-видумому ничем не отличается от внутренним но в исходном коде внутренный относится к дроби в сумме а внешний к сумме. То есть, матрица скобок для "суммы в степен" должна указать "обязательo"

Также нужно различать функции и операторы.
Функция всегда покажет границы аргумента/-ов скобками. Эти скобки надо воспринимать как часть имени. Только с этим соглашением выражение [MATH]sin(x)^2[/MATH] не может читаться как [MATH]sin(x^2)[/MATH].

Такое соглашение для операторов суммы и произведения (и вообще префикс-операторов) очевидно не существует. Если такой оператор применяется как операнд постфикс-оператора или как первый операнд инфиксного оператора, тогда оператор и его операнд обязательно надо скобить.

Кстати, иногда SMath это уже знает. Попробуйте, напр. применять постфикс-оператор факультет к сумме

[MATH lang=eng]sum(a,a,1,5)[/MATH].
Просто не удаётся пока не ставите целое выражение в скобки.

[MATH lang=eng](sum(a,a,1,5))![/MATH]

Так по моему можно поступать и в общем случае.

Впольне возможно распространить это к функциям с одним аргументом. Тогда их можно писать без скобек точно там где это и возможно для префикс-операторов.

Wrote

Впольне возможно распространить это к функциям с одним аргументом. Тогда их можно писать без скобек точно там где это и возможно для префикс-операторов.

Для функций это было бы приятно, но тогда уж следовало бы реализовать общепринятую нотацию: sin x² для квадрата аргумента и sin²x для квадрата синуса. И в этом случае нынешняя нотация sin(x+y)² должна означать совершенно противоположное, чем сейчас. Иначе снова появится визуальная неоднозначность.

Наверное, я чего-то не понимаю, но почему Вы считаете сумму и произведение префиксными операторами? Это всё же двухместные операторы, в отличие от, скажем, натурального логарифма, или (с натяжкой) от возведения в степень, если не считать показатель степени операндом.

Wrote

sin x² для квадрата аргумента

ok, если считать возведение в степень более приоритетным чем примениение функции к аргументу. Тогда возведение в степень синуса надо писать (sin x)². И правда, sin(x+y)² означало бы противоположное, чем сейчас. Так по моему можно поступать с суммой и с произведением (sum, product).

Если наоборот, т.е. примениение функции к аргументу более приоритетно чем возведение в степень, тогда синус квадрате пишется sin (x² ) и квадрат синуса sin x². sin(x+y)² означало бы то же самое как сейчас. Так наверно хорошо для остальных функциях.

Если не хочется принять разные приоритеты тогда скобки нужны в обеих случаях: sin (x² ), (sin x)². sin(x+y)² было бы неоднозначно. Пришлось бы писать (sin(x+y))² или sin((x+y)² )

Бо всех примерах все показанные скобки обязательные. Мне кажется что громадная матрица скобек не нужна, только нужен список приоритетности и некоторые правила для скобек.

Wrote

Наверное, я чего-то не понимаю, но почему Вы считаете сумму и произведение префиксными операторами? Это всё же двухместные операторы, в отличие от, скажем, натурального логарифма, или (с натяжкой) от возведения в степень, если не считать показатель степени операндом.

двухместные? По счёту черных квадратчиков sum(1) одноместный оператор, а sum(4) и product(4) четырёхместные операторы. Префиксным оператором назвал т.к. оператор перед операндом, несмотря на то что оператор может содержать переменные части (но эти от неоднозначности не страдают).

Wrote

двухместные? По счёту черных квадратчиков sum(1) одноместный оператор, а sum(4) и product(4) четырёхместные операторы.

Сорри, надо больше спать...