Alejandro Jakubi

MaplePrimes Activity


These are answers submitted by Alejandro Jakubi

Yes, the combination select + has is more syntactic (about the pieces of an expression in computational sense), but the OP seems more interested in semantic tools (about the pieces in mathematical sense). So, probably, selectfun may be more fit here:

> selectfun(y+3*x(t), x);
                                     {x(t)}
> selectfun(x(t), x);
                                     {x(t)}
> selectfun(x(t), y); 
                                       {}

Then, you just need three conditional rules like the one above, one for each case:

> r:=[conditional(a::algebraic^infty=0, _is(0<a and a<1) ),
> conditional(a::algebraic^infty=1, _is(a=1) ),
> conditional(a::algebraic^infty=infty, _is(a>1) )]:
>
> applyrule(r,b^infty) assuming 0<b and b<1;
                                       0
> applyrule(r,(1/2)^infty);
                                       0
> applyrule(r,b^infty) assuming b=1;
                                       1
> applyrule(r,b^infty) assuming b>1;
                                     infty
> applyrule(r,2^infty) ;
                                     infty

The Standard GUI has well known performance and reliability problems, particularly when handling large files. If you are editing 1000+ lines of code in the Standard GUI, not only you will meet lag problems, but you risk loosing your code because of file corruption. My advice is that you use a text editor instead as soon as possible.

Abstract linear algebra is probably one of the most requested features along the years (if not the most). See this partial list of the requests made up to two years ago. Yet, this systematic request has had no decision making effect so far...

The equivalent shortcut keys in the Standard GUI are CTRL+C and CTRL+V. Yet I very much prefer using CTRL+Insert and SHIFT+Insert. This is one of many reasons why I avoid using the Standard GUI.

Certainly, a shortcut key customization facility would be highly desirable. Nowadays, many programs  provide it.

You may try with patmach:

patmatch((x+y)^n,a::algebraic^m::algebraic,'p');p;
                                 true
                          [a = x + y, m = n]

A problem with algsubs is that it works for such expressions with products of sums if they are expanded, i.e. the product being distributed over the sum. See this toy example:

eq1 := (nu-1)*R:
algsubs((nu-1)*R = q11, eq1);
                              (nu - 1) R

algsubs((nu-1)*R = q11, expand(eq1));
                                 q11

So, for the longer example, you may try something like:

algsubs((-2*mu[2]^2+2*mu[2])*R[S]*B[n]*lambda[0]+(2-2*mu[2])*R[S]*B[n]*lambda[0]*mu[3]+
(2*mu[2]-2)*R[S]*B[n]*lambda[0]*mu[3]*n^2*N[p]^2+(-2*mu[2]+2*mu[2]^2)*R[S]*B[n]*
lambda[0]*n^2*N[p]^2 = q11, expand(eq1));

The drawback is that expand makes a long expression even longer, so that its summands may need to be recombined. Another approach is using a transformation rule like:

r:=(-2*mu[2]^2+2*mu[2])*R[S]*B[n]*lambda[0]+(2-2*mu[2])*R[S]*B[n]*lambda[0]*mu[3]+
(2*mu[2]-2)*R[S]*B[n]*lambda[0]*mu[3]*n^2*N[p]^2+(-2*mu[2]+2*mu[2]^2)*R[S]*B[n]*
lambda[0]*n^2*N[p]^2 = q11: applyrule(r,eq1);

The origin of this error message is that printf expects a string as first argument. Now, sqrt(5) returns 5^(1/2), i.e. an object of type `^`, and for arguments of types string and `^`, cat returms an objet of type `||`, not a string:

cat("Answer: ", sqrt(5));
                                              1/2
                              "Answer: " || (5   )

Idem for e.g. a string and a function call. On the other hand, it works for sqrt(4) as it returns 2, and cat returns a string in this case.

Probably, the best solution within the Standard GUI is generating a TypeMK name that typesets as the desired output: Answer, collon and sqrt(5) all in a row. One way is building a `#mrow(...);` name out of the TypeMK names for these pieces that go as "arguments" of this construct. And for this purpose, the procedure `convert/identifier`, posted by acer here, may become useful for generating these names:

convert(Answer ,identifier);
a:=StringTools:-Drop(%,1):
convert(sqrt(5),identifier);
b:=StringTools:-Drop(%,1):
nprintf("#mrow(%A,%A,%A)",a,mi(`&colon;`),b);

Note that for mrow arguments, the leading # of the generated identifiers has to be removed.

In my opinion, the usage of %-inertized function calls is a very handy tool for better control of the computation flow. In this case:

> %sqrt(4);
                                    %sqrt(4)
> value(%);
                                       2

Believe it or not, in Standard GUI there can be such differences. See this thread.

The maple executable (or a link to it, or a script launching it) does not install in the path. You may add such a link in /usr/local/bin, say. Or write there a script including the full path of this executable.

Certainly, the main problem with algsubs is that its development has been frozen (or almost) for many years. Probably since it was originally written in 1994:

> interface(verboseproc=3):
> print(algsubs);
proc(p::(algebraic = algebraic), f,
x::{name, function, set({name, function}), list({name, function})})
local g, pat, rep, vars, opt, v, bad;
option `Copyright (c) 1994 Wissenschaftliches Rechnen, ETH Zurich. All ri\
ghts reserved.`;
[...]

There are diverse alternative commands for implementing symbolic transformations more automatically. See e.g. ?applyrule ?evalindets and ?simplify,siderels. It may depend on the specificities of your computations.

Actually this is more a limitation of the is checker. Or, if you prefer, that a true theorem prover is still missing in Maple. See e.g. this thread.

In this case, as the two parts of the "proof" do work, they can be combined with a helper procedure:

combineis:=proc(p,q,r)
local a,b:
a:=is(r) assuming q:
b:=is(q) assuming p:
a and b;
end proc:
combineis(y::prime,y>0,sqrt(y)>0);
                              true

These issues have been discussed here several times in the past. See e.g. this subthread and the (sub)threads that I have linked there (note that their logical order may be upset).

In my opinion, the simplest way around is using a rule. First, a question of terminology: Sum(f@g@@k, k=0..n) is a definite (inert) sum with symbolic upper limit n. An indefinite sum would be Sum(f@g@@k, k). So, for a definite sum like this one, you can use a conditional rule for a Sum call that checks that the range is of type numeric..symbol, so that it does not apply to a fully numeric range like 0..2:

> DSumsym:=conditional('Sum'(A::algebraic,eq::equation)=
   %Sum(D(A),eq),_type(_rhs(eq),numeric..symbol)):
> E := Sum(f@g@@k, k=0..n):
> E1 := Sum(f@g@@k, k=0..2):
> applyrule(DSumsym,E);
                                  (k)      (k)
                   %Sum(((D(f))@(g   )) D(g   ), k = 0 .. n)
> applyrule(DSumsym,E1);
                                  2
                                -----
                                 \         (k)
                                  )   (f@(g   ))
                                 /
                                -----
                                k = 0

Note that a shortcomming of applyrule is that it evaluates recursively trying to reach a fix point. So, for avoiding an infinite recursion this rule DSumsym uses the %-inert form %Sum on the rhs.

First 22 23 24 25 26 27 28 Page 24 of 29