acer

20846 Reputation

29 Badges

15 years, 58 days

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

Here is another (tentative) kind of workaround,

restart;

unprotect(apply);
apply:=proc(p) p(_rest); end proc:
protect(apply);

with(VectorCalculus):

assume(x::real);
assume(y::real);

D[1]((x,y)->x^2-y^2);
       (x, y) -> 2*x

D[2]((x,y)->x^2-y^2);
       (x, y) -> -2*y

D(x->sin(x^2));
    (x) -> 2*x*cos(x^2)

What happened between Maple 2015.2 and Maple 2016.0 was that apply was changed. Here it is in Maple 2015.2. I'll note that it had issues dealing with procs with special-evaluation rules.

kernelopts(version);
   Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

showstat(apply);

  apply := proc(p)
     1   p(args[2 .. nargs])
  end proc

apply(Typesetting:-Typeset, sin(x)):
#lprint(%);
# wrong result omitted by me

And here it is in Maple 2016.0. It handles that particular spec-eval-rules example, but it can go awry on some examples with assumed names.

kernelopts(version);
   Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

showstat(apply);

  apply := proc(p)
  local P;
     1   eval(subs(P = p,P(args[2 .. nargs])))
  end proc

apply(Typesetting:-Typeset, sin(x)):
lprint(%);
  Typesetting:-mrow(Typesetting:-mi("sin", fontstyle = "normal"),
                    Typesetting:-mo("⁡"),
                    Typesetting:-mfenced(Typesetting:-mi("x")))

That implementation of apply in Maple 2016 goes wrong as used in VectorCalculus:-D under certain assumptions. (That use relates to my earlier Comment in this thread where I examined the addressof certain variables under those assumptions.)

The implementation for apply shown in the workaround above also handles that particular spec-eval-rules example, but doesn't break as used by VectorCalculus:-D under the assumptions in the original example. Ie, apply:=proc(p) p(_rest); end proc .

I should mention that I do not know how this alternative definition for apply would fare under a full regression test suite run. So I'm not going to advise anyone stick it in an initialization file.

I could also mention that I doubt that any purely Library-side implementation of apply can mimic special-evaluation-rules perfectly. Using apply already involves one full evaluation of the extra arguments, since it does not have spec-eval-rules for any extra parameters. The eval(subs(...)) approach in Maple 2016 adds yet another evaluation, so it looks more suspect. Consider the example apply(sin, ''2.1''), which returns sin('2.1') in Maple 2015.2 and also with my tentative apply implementation, but which returns a float like 0.863... in Maple 2016.2.

note. From the ?paramprocessing help page, "Like evaln, uneval can only be used for required positional parameters. It also cannot be used in conjunction with any other modifiers, or in a parameter declaration after one with the seq modifier." So putting spec-eval-rules on all extra parameters in a Library-side implementation of apply seems problematic.

@Carl Love My own Answer also (already) had an example that handled an operator (rather than an expression) using codegen[JACOBIAN].

So far the OP has ignored that germane example in my Answer. Instead he's chosen to focus on my Reply to Tom's Answer (both of which dealt with expressions) and disingenuously mischaracterize its intent.

 

@DoingMath2018 No, your previous posting shows that VectorCalculus:-D is broken (on procedures defined after certain kinds of assumptions made and after all of VectorCalculus is loaded). It's not useful to mischaracterize the details.

Did you only load all of VectorCalculus so you could try out its Jacobian export, or were there other pressing needs? And you never addressed my query of why you utilize assume rather than assuming. Why ignore all workarounds?

[edit]Anyway, the only reason I used D at all is because you had failed to mention up front that you wanted an array/vector-valued procedure rather than a Vector of procedures. I was misled by *your* own use of D in your other posting. It's not the right tool for the vector-valued procedure job. The codegen commands are. And as soon as you clarified I supplied a codegen[JACOBIAN] example.[/edit]

@tomleslie Tom, regarding your first example the behavior seems to be related to this difference between Maple 2015.2 and 2016.0.

restart; kernelopts(version);

     Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

assume(x,'real'); assume(y,'real'); f:=(x, y)->x^2-y^2:

map(addressof,[op(1,:-eval(f))]);

        [18446883966034675422, 18446883966034683358]

map(addressof,[op(indets(f(op(1,:-eval(f)))))]);

        [18446883966034675422, 18446883966034683358]

map(addressof,[op(indets(apply(f,op(1,:-eval(f)))))]); # agree

        [18446883966034675422, 18446883966034683358]
restart; kernelopts(version);
                         
     Maple 2016.0, X86 64 LINUX, Feb 16 2016, Build ID 1113130

assume(x,'real'); assume(y,'real'); f:=(x, y)->x^2-y^2:

map(addressof,[op(1,:-eval(f))]);

        [18446884548440282622, 18446884548440291006]

map(addressof,[op(indets(f(op(1,:-eval(f)))))]);

        [18446884548440282622, 18446884548440291006]

map(addressof,[op(indets(apply(f,op(1,:-eval(f)))))]);  # differ

        [18446884548440289598, 18446884548440291998]

And VectorCalculus:-D is using apply, at a key juncture rather than making a function call directly, and so the names don't match when taking the derivative (hence the 0 result).

showstat(VectorCalculus:-D,20);

   VectorCalculus:-D := proc(f)
   local Opr, Index, d, i, n, sol, g, idx, F, x, _F, bb;
          ...
     20       g := apply(d,sol);
          ...
   end proc

I do not know whether this version specific change in behavior (of apply, under assumptions) was intentional, or whether there is some reason why VectorCalculus:-D utilizes apply.

@dharr I agree, and I apologize if I came off the wrong way.  Vote up, btw.

In versions Maple 2016 and earlier the Java GUI had a user-preference which could be set to display legends automatically for 2D plots. But that seems to have been removed/disabled in Maple 2017.

It was a checkbox, avaiable via Tools->Options-Display from the main menubar.

It labelled the multilple curves like, "Curve 1", "Curve 2", etc, alongside short line segments of the appropriate color.

@dharr Your call to rsolve solved the mixed recurrence to obtain a closed form formula for the general term. And perhaps that is what the OP actually wanted at end.

But the OP asked for the "general recurrence" (involving s(n), regardless of parity) which is not the closed form formula for the general term.

@tomleslie If you execute SE(x) in your code then the result is just sin(Pi*x)*exp(-x^2)/(x*Pi) , and that is what is being passed to inttrans[fourier].

So, as far as taking the fourier transform goes, you've got the same thing as Carl's initial response. By which I mean that the exprerssion obtained by the symbolic call SE(x) no longer contains any piecewise, Dirac, unevaluated `if`, or other mechanism to handle the singularity. But it seems that the OP did want that generality.

@DoingMath2018 If your input procedure doesn't have conditionals and branching (ie. are simple operators that utilize a formula) then handling an arbitrary number of dependent variables and instead using an expression doesn't seem to present great difficulty.

For example (noticing that the dummy variable of integration, r, is correctly skipped and is not one of the independent variables):

restart;

expr := [x^2-y^2+a*z+Int(cos(q*r*s),r=0..1)];

[x^2-y^2+a*z+Int(cos(q*r*s), r = 0 .. 1)]

vars := [op(indets(expr,And(name,Non(constant),satisfies(u->depends(expr,u)))))];

[a, q, s, x, y, z]

exprJ := unapply(VectorCalculus:-Jacobian( expr, vars ), vars):

evalf(exprJ(0.1,0.2,0.3,0.4,0.5,0.6));

Vector[row](6, {(1) = .6, (2) = -0.5997840278e-2, (3) = -0.3998560185e-2, (4) = .8, (5) = -1.0, (6) = .1})

# check
map(diff~,expr,vars);
evalf(eval(%, Equate(vars,[0.1,0.2,0.3,0.4,0.5,0.6])));

[[z, Int(-r*s*sin(q*r*s), r = 0 .. 1), Int(-q*r*sin(q*r*s), r = 0 .. 1), 2*x, -2*y, a]]

[[.6, -0.5997840278e-2, -0.3998560185e-2, .8, -1.0, .1]]

 

Download VCJ_arb.mw

Above I have constructed a single Vector-valued procedure rather than a Vector of procedures. I'm not sure which you want.

If you really do prefer to use an input operator rather than an input expression then you could look over my Answer above.

I think it would be easier to learn how to leverage Maple's functionality than it would be to implement your own basic CAS.

It is still unclear to me how you plan to subsequently utilize this Jacobian-thing that you're after. Providing more details of the input example class and also how the result will be subsequently utilized should surely be a core part of the question.

Have a look at the Help pages for the Student:-Calculus1 package.

@tomleslie The OP made it quite clear in his Question that he wanted to act on operators/procedures rather than expressions. That was the central point of the Question.

Your code deals with function calls which evaluate to expressions prior to Jacobuan being called. So your suggestion is not what was requested.

One could map unapply over an expression-based solution like yours, after the fact, to get a result with operators. But that is a kludge generally weaker than using D (which also has some abilities to deal with conditionals and code branching within the procedure, and that otherwise mostly gets wrecked/ignored by a function call to produce an expression result).

@tomleslie Investigating the older behavior is a good idea. But the following does not agree with one of your examples (even if put in a single execution group).

restart;

kernelopts(version);

`Maple 2019.0, X86 64 LINUX, Mar 9 2019, Build ID 1384062`

with(VectorCalculus):

# assume(x, 'real');
# assume(y, 'real');

D[1]((x, y) ->x^2-y^2);

proc (x, y) options operator, arrow; 2*x end proc

 

Download D_TL.mw

@Carl Love The example that I showed produces the same results in my Maple 2019.0 as it did in what I posted from Maple 2018.0.

I suspect that you have not noticed the key aspects of my two alternatives. One uses procedure f defined before loading the package, and the other used unapply afterwards. I did not claim that :-D would work on the operator defined literally as you have it, after loading the full VectorCalculus package and placing the assumptions (which is literally similar to what the OP had).

restart;

kernelopts(version);

`Maple 2019.0, X86 64 LINUX, Mar 9 2019, Build ID 1384062`

with(VectorCalculus):

assume(x, 'real');
assume(y, 'real');

:-D[1]( unapply(x^2-y^2, [x,y]) );

proc (x, y) options operator, arrow; 2*x end proc

:-D[2]( unapply(x^2-y^2, [x,y]) );

proc (x, y) options operator, arrow; -2*y end proc

restart;

kernelopts(version);

`Maple 2019.0, X86 64 LINUX, Mar 9 2019, Build ID 1384062`

f := (x, y) -> x^2-y^2;

proc (x, y) options operator, arrow; x^2-y^2 end proc

with(VectorCalculus):

assume(x, 'real');
assume(y, 'real');

:-D[1](f);

proc (x, y) options operator, arrow; 2*x end proc

:-D[2](f);

proc (x, y) options operator, arrow; -2*y end proc

:-D[1]( unapply(x^2-y^2, [x,y]) );

proc (x, y) options operator, arrow; 2*x end proc

:-D[2]( unapply(x^2-y^2, [x,y]) );

proc (x, y) options operator, arrow; -2*y end proc

 

VCD_M2019.0.mw

Trying to export package "overloads" of kernel builtins is difficult to get exactly right (and not always possible). [edit] If Tom is correct and this is a regression breakage then I do not yet know whether the bug is Library-side or kernel-side.[/edit]

Please upload a worksheet, or add a comment with the full details to this thread. Please don't post a duplicate thread, which is unhelpful.

@Carl Love Yes, simplify with side-relations can just do this:

restart;

G:=Groebner:-Basis({a+b+c-1,a^2+b^2+c^2-2,a^3+b^3+c^3-3},
                   plex(c,b,a),characteristic=0,output="basislm"):

lprint(G);
   [[6, a^3, 6*a^3-6*a^2-3*a-1], [2, b^2, 2*a^2+2*a*b+2*b^2-2*a-2*b-1],
    [1, c, a+b+c-1]]

Groebner:-NormalForm(a^4+b^4+c^4,G,plex(c,b,a),characteristic=0);

                         25/6
First 69 70 71 72 73 74 75 Last Page 71 of 443