Непонятно из примера, что нужно получить. Вангую, что первый после моего ответ будет в стиле «вот алгоритм: echo '(x [z pz][pd (px [py y])])'». Давай подробнее.

Я ошибся в примере должно быть не (x [z pz][pd (px [py y])]), а ([z pz][(x pd) (px [py y])]). Задача преобразовать ряд так, чтобы легко можно было проверять другие ряды на эквивалентность ему.

что означает (x pd) ?

А исходное выражение имеет смысл? Вот это: pd x px py y z pz. Какого типа? Вообще это все типизировано? Я спрашиваю, потому что пока непонятно, что делает pz в конце и вообще, что это за нотация.

Расставь скобки, что ли.

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

Пипец каша в голове. Нахватался умных слов и давай умничать.

Вот этот «оператор» pz в конце, на что он действует?

pd x px py y z pz - это сложный оператор, который получается произведением более простых операторов. В математике оператор - преобразование на множестве функций, где функции приводится в соответствие функция.

В математике оператор - преобразование на множестве функций, где функции приводится в соответствие функция.

Замечательное определение! То есть матричный оператор на R^3 уже не оператор?

А теперь расскажи нам про свою нотацию. Обычно в книгах можно увидеть что-то вроде «Af» (оператором A подействовали на f), <\delta,f> — запись в виде скалярного произведения итд.

Но вот записи z pz я не встречал. Что это за левый оператор такой? Чем он отличается от правого pz z?

Для меня то, что ты написал — просто набор символов, как и для других, как я понимаю. Что ты хотел нам сказать? Какова твоя задача? Что такое x,y,z? И что такое pd, px, py, pz?

не справляешься с формализмом? пиши f(x,y) и не будет проблем

Ты какой-то бред написал. Там хоть ассоциативность-то есть?

Какая-то каша. Похоже, что и в голове. Поопределяй всё нормально.

Например, x,y,z in gl(V), V - векторное пространство. pd, px, py, pz : gl(V) -> gl(V).

Но вот записи z pz я не встречал. Что это за левый оператор такой? Чем он отличается от правого pz z?

М.б. (z pz) - оператор (скалярное произведение z_i*diff(~,z_i) ), а (pz fz ) - функция (оператор pz подействовал на z : diff( fz_i,z_i) - (fz_i ???))

Ты скобки-то расставь или опиши задачу изначальную, а с определением оператора я уж как-нибудь справлюсь.

1) Как парсить входной ряд [pd x px py y z pz] - почему [z pz] надо склеить, а [x px] не склеивать? 2) Результат «pd px» видимо оператор, где указано, что он коммутативен с pz ? 3) Цель для преобразователя не просек по образцу.

(Похожим образом пытался навелосипедить генератор для avx2-подсчета производных векторной f(a,g(b,h(c,v)))- «отложил», Может кто нить знает какие буквари читать? где инфа? неужели пишут вручную?)

два чая этому анонимусу. А, я как просто bsd-шник, не формульщик не всосу «pd»,то в тред-примере,это што?

Наверно производная по параметру(ам), которые входят в операторы px и py (а в pz - не входят, раз перестановочно). А вообще xz.

2ТС: Если это, что-то для поиска в справочнике(базе) по дифурам, то как быть с переименованием переменных и функций ?

pz pd вот что совершенно с логикой не сходится, кажется, нащупал нить, ща ещё немного поразбираюсь.

А такого нет. В исходном [pd x px py y z pz] - pd слева, действует только на px py. В итоговом ([z pz][(x pd) (px [py y])]) - (x pd) действует на них же. А [z pz] не замечает написанного справа и действует только на предполагаемое справа, как и в исходнике. Так думаю.

Постараюсь описать задачу попонятливее.

Есть одно выражение, которое после подстановки разворачивается в сумму из большого числа выражений вида [pd x px py y z pz] - здесь я обозначил квадратными скобками некоммутативное произведение элементов {pd px py pz x y z} (фигурными скобками обозначаю множества). Произведения некоммутативны в общем случае, но имеют место дополнительные условия, что некоторые элементы в таких произведениях всё же коммутируют и тогда встаёт задача определение эквивалентности выражений.

У меня есть идея преобразовывать выражения в виде смешанных коммутативных и некоммутативных произведений, например (x [z pz][pd (px [py y])]), где (a b) - коммутативное произведение элементов a и b, а [a b] - некоммутативное. Это при том, что есть рабочая программа которая определяет эквивалентность, например ([z pz][(x pd) (px [py y])]) и ([z pz][(pd x) (px [py y])]). Как верно подметил анонимус из треда этим примерам также эквивалентен и ([z pz][pd ([x px] [py y])]), но у программы с этим случаем трудности. Надеюсь, что с выбором какого-либо одного алгоритма преобразования до такой проблемы не дойдёт.

Думаю сообщать программе дополнительные условия в виде множеств некоммутирующих элементов, например {px x} {py y}. При этом верны:

py y px x != py y x px; py y px x == py px x y;

Однако некоммутирующие {pd px}{pd py} не эквивалентны {pd px py} - утверждение:

pd px py == pd py px

в первом случае верно, во втором ложно.

То что элементы подразделяются на функции и операторы, означает только то, что операторы по возможности лучше держать правее от функций. Пока не думаю что это принципиально. Ну и такая мелочь, что функции априори коммутируют друг с другом.

Смотри в сторону permutation groups, transpositions.

Да тут всю систему менять надо!

К какой-либо математике это имеет очень поверхностное отношение. Нет строгости. Потому как у тебя есть некое множество «функций», скажем, A, и «операторов», скажем, B. У операторов из B должна быть область определения, скажем, функции из A и область значений.

Но из ОП мы видим следующее «px py pz которые действуют на соответствующую из функций». Т.е. у каждого из операторов своя область определения, а область значений неизвестна вовсе.

Ты должен или задать операторы по типу A->A, или для всех возможных комбинаций описать область значений. Для произведений из 2-х «операторов» у тебя будет 4^2 правил, для 3-х «операторов» 4^3, итд. Т.е. правил будет так много, что ты задолбаешься их описывать.

Короче задача ясна — определить эквивалентность 2-х выражений по некоему набору правил. Нет только чёткой формулировки этих правил. Советую отбросить математику и сформулировать хоть на бананах.

Реально, из твоей формулировки выражения py y или px x имеют смысл, а px py y или py px x — не известно, т.к не понятно, может ли px действовать на py y

Тут для начала надо понять, как действует его операция («умножение»). А потом уже группами заморачиваться. Вот я нифига не пойму из его поста

Насколько я понял, у него px ничем особым не отличается от любого другого элемента, кроме как тем, что для него предопределена коммутативность с определенным множеством элементов.

Судя по постам ТС, наиболее близкое понятие, описывающее его конструкцию — это полугруппа. И вот он хочет привести любые произведения элементов из этой полугруппы к одному универсальному виду, чтобы легче было определять их эквивалентность.

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

Пока в голову приходит тупое «двигаем влево/вправо пока двигается и некоммутриует».

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

Насколько я понял в итоге, задача придумать какое то «нормализованное» представление для такого ряда. А оператор может действовоать на несколько функций, или в результате действия оператора на функцию может получать другая функция напр px x->y на который уже действует py? Вообще для читаемости конечно лучше операторы другим регистром обозначать...

В общем алгоритм сравнения (на эквивалентность) таких рядов я могу предложить, а вот алгоритм решения исходной заадчи и правда как то не клеится...

Алгоритм сравнения такой. Пусть у нас есть ряд из N элементов. Сопоставим каждому элементу некоторое число P, такое что после сортировки по этим числам не будут нарушены заданные соотнощения коммутативности, но два эквивалентных ряда будут иметь один и тот же вид. Числа задаются следующим образом:

1) Нумеруем элементы в лексикографическом порядке (т.е. тупо сортируем по имена и нумеруем от нуля до N-1), это будут исходные числа P.

2) заводим счетчик Q=N, идем по неотсортированному (исходному) ряду. Если встречаем оператор, то:

2.1) проходим ряд до конца, всем элементам с которыми оператор не коммутирует добавляем значение Q.

2.2) Увеличиваем Q вдвое.

Все, сортируем ряд по P, дальше два обработанных таким образом ряда можно тупо сравнивать поэлементно.

Или попонятливее:

 man tsort (в новых дистрах может не быть)
 По входной строчке пишем файлик in1.txt , что с чем не коммутирует:
(т.е. некоммутирующие пары в нужном порядке)

pd px
pd py
x px
py y
z pz

Говорим: sort -u in1.txt | tsort >st1.txt Также для второй последовательности. Сравниваем: diff st1.txt st2.txt

А такие [px x pd x px] - x и px дважды, могут быть ?

Кстати [x px x] и [px x x] равны ? (т.е. px действует только на ближайший x или на все, которые справа ?)

[px x pd x px]

да

[x px x] и [px x x] равны ?

при некоммутирующих {px x} нет

Пожалуй скажу, что ноги этой задачи растут из квантовой физики, а px - из оператора импульса: px = - i * h * d/dx

[px x pd x px] - да

tsort не умеет циклы. Обход - пронумеровать многократные вхождения.

px = - i * h * d/dx

А pd - что такое ?

А pd - что такое ?

От фонаря взят.

при некоммутирующих {px x} нет

Что такое px x - понятно, а x px - это что? Ты б объяснил, что именно значит твоя запись, тебя уже сколько раз попросили.

Если гора не идет к anonymous-у, то anonymous идет к горе :)

Предлагаю приземлить задачу, переформулировав еъ на бананах, напр. на maxima(-е).

px(f):= -I*h*diff(f,x);
py(f):=I*h*diff(f,y);
pd(f):= f;

t1: fx(x)* px(py(pd( fy(y)*fx(x)* U(x,y) )));
t2: fx(x)* py(px(pd( fx(x)*fy(y)* U(x,y) )));

expand(t2-t1);

Обозначения: U(x,y) - «подразумеваемое справа» (волновая функция), иначе maxima не умеет (или не умею ее готовить). px(f), py(f), pd(f) - операторы. fx(x), fy(y) - функции, у ТС: x, y.

t1 это [x px py pd y x] , а t2 это [x py px pd x y].

Ну и плюсом идет, что скобками ограничевается область действия оператов.

А тебе Cadabra как готовое решение не подойдет?

Сходу счас уже не вспомню других пакетов, которые умеют такие выражения упрощать. Если выльется все в диаграммы и крит. индексы потом, то советую прогу FORM, но ее непросто найти. Умеет в том числе работать и с некоммутативными моделями.

в руте неабелевость тоже должны были давно уже написать...

На будущее: пользуйся стандартными обозначениями (шляпки писать долго, так что без них по смыслу можно все равно догадаться):

{A, B} - это антикоммутатор операторов A, B

[A, B] - это коммутатор

p_x, p_y, p_z - это компоненты оператора импульса

p_d - ваще хз, что ты тут имел ввиду. Надеюсь, не производная по размерности пространства, иначе дальше у тебя будет много слез и мата.

P.S. алгоритм перестановок расписан в любом учебнике по КТП, где есть N-, T-, S- упорядочивание (в Боголюбове-Ширкове вроде был).

Кароч, у чувака появляется тьма операторных слагаемых при решении уравнения Шредингера методом теории возмущений. И он решил их сгруппировать. Но я хз, почему он решил действовать именно так. Это далеко не самый эффективный метод решения уравнения Шредингера.

p_x x как и x p_x особого смысла вне контекста не несет - они могли взяться откуда угодно и адекватная физ.интерпретация варьируется от одного применения к другому.

все в том посте - эрмитовы операторы, не обязательно абелевы. интерес представляют выражения вида \int \Psi^{+} (ABCDEF) \Psi d^n x. Веселье в том, что интегралы такого вида обычно довольно сложны, а операторное выражение ABCDEF можно нехило упростить и снизить сложность алгоритма вычисления интеграла, если мы знаем, кто с кем коммутирует или некоммутирует на некоторую величину (например, [px, x]=-i, h=1).

все в том посте - эрмитовы операторы

Чет не пойму никак, что такое x,y,z :

 операторы I*h*diff(U, [x, ...] )  (какие?);
 или у ТС - функции от сооств. переменной ;
 или просто умножение на соотв. переменную.

тогда получается на maxima:

px(f):= -%i*h*diff(f,x);
py(f):= -%i*h*diff(f,y);
pz(f):= -%i*h*diff(f,z);
fx(f):=x*f;
fy(f):=y*f;
fz(f):=z*f;

fx(px(pz(px(fx(U(x,y,z)))))); /* все действует направо */

/* лень писать скобки */
D(v,f):=block([d,n,i],d:f,n:length(v),for i:1 thru n do d:v[n+1-i](d),d);
D( [px,fx], U(x,y,z) );

/* коммутационное соотношение = -i*h */
expand( D([px,fx],U(x,y,z)) - D([fx,px],U(x,y,z)) );

/* пример ТС: */
a: D( [fx,px,py,fy,fz,pz], U(x,y,z) ); /* первый */
b: D( [fz,pz,fx,px,py,fy], U(x,y,z) ); /* второй */
expand(a-b); /* видим 0, значит равны */

2ТС: Всеже интересно узнать какая задача целиком.

да, это просто умножение на x,y,z.

Задача - например, расчет оператора эволюции для какого-нибудь нелинейного гамильтониана. Это exp(-iHt), H=p^2/2m + kr^2 + gr^4.

Один из вариантов расчета - разлагать экспоненту в формальный ряд, упрощать его (перестановка множителей в слагаемых + пересуммирование ряда).

Но так никто не делает, ибо наркомания))

Других адекватных вариантов я не могу счас вспомнить

Попалась книжка по квантам: «Численные методы квантовой статистики, Кашурников В.А., Красавин А.В.» - понравилась приземленностью, и свежая.

2aido: По вопросу из linux.org.ru/forum/science/12588919 :

Похоже это «ru.wikipedia.org/wiki/Процесс_Грама_―_Шмидта» , если символные вычисления.

Если численные (с ошибкой измерений или вычислений), то метод другой (разложение по собственным векторам): «ru.wikipedia.org/wiki/Метод_главных_компонент» или «en.wikipedia.org/wiki/Principal_component_analysis» .

Те собственные вектора, которые окажутся меньше точности - можно похерить.

Где-то, по ссылкам из вики была простая С-реализация, есть в maxima, octave.

2aido: похоже соврал, сорри.

да я ж говорю, что меня пока глючит со скалярными произведениями. если б были обычные вектора, то Гаусса или Грама-Шмидта там без проблем можно использовать. В принципе, предложенный мной алгоритм очень похож на Грама-Шмидта, но название его я за 6 лет уже забыл, а метод в голове остался)

Исправляюсь: «ru.wikipedia.org/wiki/Разложение_Холецкого» A=L x L^T

Реализации: «rosettacode.org/wiki/Cholesky_decomposition»

в точности то, что надо!