Christian Wolinski

MaplePrimes Activity

These are replies submitted by Christian Wolinski

@vv I did not notice the OP was asking for x of y rather than y of x.

@tomleslie Domains was always intended as a directory, with only the base implements, to be augmented by the user.

@Jsevillamol Add this line to the start of the procedure: print('procname(args)'); print('procname');. g is initialized to your GI, for example: op('t[1,2]'); op('u[a]');PrincipalIdeal is part of Domains package. Use showstat(PrincipalIdeal);. I think you will find there the procedure you are trying to write yourself.

@minhhieuh2003 ((n, m)->'log[n]'(m))(a, b*x+c);

@Carl Love What I gave you is an empty example. All it does is count invocations of function g in trivial constructions.

The expression is the fundament of SC. A code is an expression and an expression is a code. This duality makes SC codes easy to read and understand. Composing, manipulating, sampling, evaluating, inspecting, decomposing is first in SC. I am not saying "it is available", I am saying "it is the base". And so as I would expect [[[[[[g[0](0)]]]]]] is same as [[[[[[g[0]]]]]]](0), but unexpectedly [[[[[[g[0](0)(0)]]]]]] I find is not [[[[[[g[0]]]]]]](0)(0) nor [[[[[[g[0](0)]]]]]](0). Even more surprisingly the last two are equal. Ofcourse all of this can be explained by kernel rules but it matters not. What is clear Maple is not SC based. It is OOP based. The consequences can be seen in the results.


My first Maple was 5.4 and it certainly was SC base. They have alluded they would be implementing modules and overloading. I have easily imagined the implements. Why they sacked SC I cannot imagine.

@vv If you do not know what is expected then you can safely assume this cup is not what you would drink. There are other threads where you would contribute instead.

@Carl Love Codes are meant to be legible, understandable, presentable, explainable. If this is intended by the designers, then how is the following interpreted? Please read the code and compare it to the the results. Interpret the code before it executes. I woke myself from my Maple V slumber into this Maple 2017 horror show:


g:=proc() local j; j:=op(procname); j:=g[j+1]; applyop(x->eval(x,2),0,'j(args)'); end;

f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);
f(0), f(0)(0), f(0)(0)(0);


@Carl Love Is it safe to say symbolic computation is dead with Maple?

What is RonanRoutines?

@Ronan How about this:


A := (lhs-rhs)(eq3);
L := ([op]@indets)(%, radext);
R := convert(L, RootOf):
(evala@Norm)(subs(L =~ R, A), {}, indets(R, algnumext));
# or in a case when needed:
subs(R =~ L, (evala@Norm)(subs(L =~ R, A), {}, indets(R, algnumext)));

Thumb if you like.

Can you specify which science, subject produced this matrix?


You can use this code.


cH := proc (x) options operator, arrow; conjugate(x) = abs(x)^2/x end proc;
rH := proc (x) options operator, arrow; x = 2*Re(x)-conjugate(x) end proc;
fe := proc(f) frontend(f, [args[2..-1]],[{Non}({op(procname)}), {}]) end;

A := Matrix([[phi, conjugate(psi), chi, conjugate(rho)], [psi, -conjugate(phi), rho, -conjugate(chi)], [lambda1*phi, conjugate(lambda1)*conjugate(psi), lambda2*chi, conjugate(lambda2)*conjugate(rho)], [lambda1*psi, -conjugate(lambda1)*conjugate(phi), lambda2*rho, -conjugate(lambda2)*conjugate(chi)]]);
dA := LinearAlgebra:-Determinant(A);

map(cH, [phi, chi, rho, psi]);
T[1] := map(numer@(lhs-rhs), %), plex((op@map)(lhs, %), (op@map)(op@lhs, %));

map(expand@cH, [lambda1-lambda2, conjugate(lambda1)-(lambda2)]);
T[2] := map(expand@numer@(lhs-rhs), %), plex(op(indets(% ,specfunc(conjugate))), op(indets(% ,specfunc(abs))));

T[3]:=map(expand@numer@(lhs-rhs), %), plex(op(indets(% ,specfunc(conjugate))), op(indets(% ,specfunc(Re))));

fe[specfunc(anything, {conjugate, abs})](expand@simplify, dA, T[1]);
collect(%, abs, distributed, factor);
fe[specfunc(anything, {conjugate, abs})](expand@simplify, %, T[2]);
fe[specfunc(anything, {conjugate, abs, Re})](expand@simplify, %, T[3]);
dA2:=fe[function](collect, %, indets(%, anyfunc(dependent({lambda1, lambda2}))), distributed, factor);

collect(dA2, Re);
coeff(%, Re(conjugate(phi)*conjugate(rho)*chi*psi), 1)+8*Im(lambda1)*Im(lambda2):
(% = expand(convert(%, conjugate)))*Re(conjugate(phi)*conjugate(rho)*chi*psi);
dA3 := collect(dA2-lhs(%), indets(%, anyfunc(dependent({lambda1, lambda2}))));


Thumb if you like.

Following is an example which I consider a failure in symbolic computation. Am I overreacting? It simply demonstrates the fact that unless the parameter is inert (not active like g()) it cannot be safely used in an identity because it may be distributed. 


g := proc(n) global i; local j;
   if not type([i], [integer]) then i := 0; fi;
   j := i;
   i := i + 1;

A := f = a + b + c;
W[1] := 'f'(g());
W[2] := '%' = %;
W[3] := (''f'' = 'f')(g());  


@acer The composition rule demonstrated by Op & Op2 was a clad rule of Maple programming. It holds true in 5.4, it does not hold true in Maple 2017. I did not notice, or maybe I forgot. I am interested to know when this change was implemented. Where is this announced, where is the narrative for this change?

So which versions fail this and how is this explained. I feel like this is an old issue.

Edit: the results wont be equal, but they should be similar.


Op := proc(R,F)
 a := R, R;

Op2 := proc(R,F)
 a := R, R;
 a := a();

([Op] = [Op2])(rand(1 .. 9), [f, f]);


1 2 3 4 5 6 7 Page 2 of 7