## 19132 Reputation

14 years, 288 days

## constant?...

How would you want to handle supplying the constant to appear in the range of integration, depending on f?

You can write an extension procedure, which gets picked up by convert(...,Int) .  Eg,

showstat(convert/Int/from[invfourier]);


## comment...

Kitonum is using the parametric calling sequence of the plot3d command, where each of the three entries is a procedure (of two parameters).  The names of the parameters of the procedures are just dummy names. You could label them "y" and "t" or what you wish, no?

You asked for a particular meaning, ie, "In 3D plot, the axis must be ( y, t, X(t)*sin(y) )". So how are the meaning for the two parameters not understood?

## "module" as term for .dll...

@Carl Love Sometimes the MS-Windows folks refer to a .dll as a module.

It sounds as if the OP is trying to run maple under a C/C++ debugger.

If the OP created the .dll himself then it'd up to him to build/link it with debugging info. I'm not sure how much that'd help him, though.

Maple does not ship with debugging info/versions of all its own .dlls .

There are a lot of details missing in this question.

## knowledge of "outer" ranges...

@max125 The int command does not have special evaluation rules, by which is meant that it evaluates its arguments up front, before computing.

In consequence when you enter nested int calls the inner one is computed up front, and when that happens it does not have knowledge of the outer integrals ranges of integration.

For this example, the inner integrals are computed without the knowledge that x>-1, x<1.

But when you use the collapsed syntax of a single call to int (with multiple ranges supplied) then it can have that knowledge.

For you example, it makes a difference to the form that is attained for the middle integration.

 > restart;
 > kernelopts(version);

 > assume(x>-1, x<1);
 > int(int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2)),x=-1..1);

 > restart;
 > int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2));

 > int(%, x=-1 .. 1);

 > restart;
 > assume(x>-1, x<1);
 > int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2));

 > int(%, x=-1 .. 1);

 > restart;
 > int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2)) assuming x>-1, x<1;

 > int(%, x=-1 .. 1);

 > restart;
 > int(int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2)),x=-1..1);

 > restart;
 > # This one does not succeed, for a complicated reason # relating to the specific implementation of assuming. # It worked, as first example above, with assume.
 > int(int(int(1, z=2*sqrt(x^2+y^2)..2),y=-sqrt(1-x^2)..sqrt(1-x^2)),x=-1..1) assuming x>-1, x<1;

 >

## integral entry from palette...

When entering an integral (as typeset 2D Math) from the palette, don't overwrite the Roman (upright font) d with the name d, when inserting the dt part. Only enter the t, after the d. A visual indication that it's not right is that the dt has the d in italics.

## colorbar...

@Alger A 3D plot in Maple doesn't support a legend, and the choices of location of a caption are limited.

So it may be that a colorbar is preferable, even though it is finicky to get it displayed just right.

Here is one way to get that:

essai_colorbar.mw

## via coloring, or animating...

You have four-dimensional data.

Two common ways to visualize that in 3D plotting is to choose one of the four dimensions and use it for either color/shading or repesentation in time (for an animation).

It may be that either z[i] or A(...i...) is a nicer choice for that treatment.

But it's not possible to say with assurance which is nicer since it will depend on how all the data lies.

And you have not given us the data.

## great...

@Carl Love Great.

So I suppose you could add that to the ModuleLoad.

Perhaps the ModuleApply could accept anything, and return the first argument if it were not of the new type RealIntervals.

## LaTeX array...

The fancy GUI table cannot be converted to LaTeX, though it is possible to generate some lengthy XML. Doing anything with all that in LaTeX would likely be very difficult.

The easiest thing would be just to convert the 2-column Matrix to LaTeX, which produces \begin{array} ... \end{array}. If you needed to you could substitute "tabular" for "array" in the LaTeX string generated.

Below, I strip out the left- and right square brackets.

I notice that the Maple LaTeX command is mis-treating floats, when handling the Matrix. So it turns 1.2345e-11 into 0.000000000012345 which is not nice. So I'll include some patch-ups involving float notations. (Goodness, it'd probably be easier to write a better Matrix-to-LaTeX export from scratch. Oh well.)

 > restart:
 > n:=1: m:=2:   E:= 1.75*10^(3):   l:=10:   II:=10^(3):   v:=10:   M:=10:   a:=0.1:   g:=9.8:   tf:=10:
 > w1:=sqrt(E*II/m)*(Pi/l)^2: a_0:=Pi*a/(w1^2*l): m_0:=M/(m*l): v_0:=v/w1: delta:=4*m*g*l^4/E*II*Pi^5: tau:=w1*t:
 > p:=sin(v_0*tau)*sin(v_0*tau): h:=sin(v_0*tau)*cos(v_0*tau): z:=2:
 > M:= tau -> 1+2*m_0*sin(v_0*tau)*sin(v_0*tau): C:=tau -> 2*m_0*(v_0*tau)*sin(v_0*tau)*cos(v_0*tau): K:=tau ->1-2*m_0*v_0^2*sin(v_0*tau)*sin(v_0*tau)+2*m_0*a_0*cos(v_0*tau)*sin(v_0*tau): f:=tau -> m_0*Pi/2+m_0*v_0^2*p*z-m_0*a_0*h*z: X:=x(t):       sys:= delta*(M(t)*diff~(X, t\$2)+C(t)*diff~(X, t))+K(t)*X=f(t):
 > IC:=x(0)=0,D(x)(0)=0: # or you can define any Initial conditions sys1:={sys,IC}:
 > numSol:=dsolve(sys1,numeric,method=rkf45, range=0..1, output=listprocedure):
 > xx := eval(x(t), numSol):
 > V1 := Vector([seq(0.1..1, 0.1)]):
 > V2 := map(xx, V1):
 > M := ;

 > with(StringTools):
 > SubstituteAll(Substitute(Substitute(latex(M,'output'='string'),                                     "\\left[ ",""),"\\right]",""),"","");

 >
 > M := ;

 > with(StringTools):
 > SubstituteAll(Substitute(Substitute(latex(M,'output'='string'),                                     "\\left[ ",""),"\\right]",""),"","");

 > SubstituteAll(SubstituteAll(Substitute(Substitute(latex(M,'output'='string'),                                     "\\left[ ",""),"\\right]",""),"",""),"\\tt","");

 >

## procedure vs appliable module...

@Carl Love Vote up.

I think that the extension mechanism requires an actual procedure, which can be wrapped around an appliable module. (It's also possible that you tried that as a second attempt, but neglected to clear the remembered result.)

 > restart;
 > kernelopts(version);

 >
 > SimplifyIntervals:= module() local    x::identical(x),    ModuleLoad:= ()->       TypeTools:-AddType( #recursive type: put base cases 1st!          'RealIntervals',          Or(             specfunc(RealRange),             set(realcons),             'specop'('RealIntervals', {intersect, union, minus})          )       ),    Deconstruct:= (IN::RealIntervals)->       if IN::specfunc(RealRange) then convert(x::IN, relation)       elif IN::set(realcons) then Or((x =~ IN)[])       elif IN::minus then And(thisproc(op(1,IN)), Not(thisproc(op(2,IN))))       else if(IN::union, Or, And)(map(thisproc, [op(IN)])[])       fi,       ModuleApply:= proc(IN::RealIntervals)    local pts, ints;       (pts,ints):= selectremove(type, [solve(Deconstruct(IN), x)], realcons);       union(sort(ints, key= (p-> if(op(1,p)::realcons, op(1,p), op([1,1],p))))[])             union {pts[]}           end proc ;    ModuleLoad() end module:
 >
 > expr := (((RealRange(-infinity, 1) intersect RealRange(Open(-1), infinity))            minus RealRange(-1/3, 1/3)) minus {0}) union {-2,2};

 >
 > simplify/intervals := SimplifyIntervals: forget(simplify);
 >
 > simplify(expr, intervals); # Does not use the appliable module

 >
 > simplify/intervals := proc() SimplifyIntervals(args); end proc: forget(simplify);
 >
 > simplify(expr, intervals); # Uses the procedure

 >

## no such error now, for me...

@Spirithaunter After making the replacements I suggested throughout I no longer see that error message at all.

Spirithaunter_01.mw

## oddness...

@vv I tried to give the OP some advice about not using unapply (and a procedure call) when an expression would serve. That is enough to avoid the problem.

But the originally exhibited problem is deeper, I think. In the examples below, what is the essential difference between Vectors boo and rah? Why does mapping eval across rah have such an effect, while applying rtable_eval (to rah, or V, or anything in sight, with or without its inplace option) does not have a similar effect?

I agree with you that the construction was unusual. It seems like advice might include: don't unapply a Vector and then subsequently change that Vector's entries.

 > restart;
 > kernelopts(version);

 > V := Vector(2);

 > f := unapply(V, t);

 > V[1] := t^2; V[2] := t^3;

 > rah:=f();

 > lprint(eval(rah,1));

Vector[column](2, {1 = t^2, 2 = t^3}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])

 > K := unapply(rah,t);

 > K(3); # like the OP's problem

 > boo := map(eval,rah);

 > lprint(eval(boo,1));

Vector[column](2, {1 = t^2, 2 = t^3}, datatype = anything, storage = rectangular, order = Fortran_order, shape = [])

 > L:=unapply(boo, t);

 > L(3);

 > lprint(eval(K,1));

proc (t) options operator, arrow; Vector(2, {(1) = t^2, (2) = t^3}) end proc

 > lprint(eval(L,1));

proc (t) options operator, arrow; rtable(1 .. 2, {1 = t^2, 2 = t^3}, datatype = anything, subtype = Vector[column], storage = rectangular, order = Fortran_order) end proc

 >

## different instances of the "same" name...

@student_md Suppose you have an expression already, involving the global name t. And then you construct a procedure (operaotr) using just the arrow notation directly. The parameter t of the procedure (operator) is different from the global name t inside the expression. They look the same, but they are quite distinct. When the procedure is called it uses the value of it argument wherever that name is used in the body of the procedure. But in the following example the parameter t does not occur in the expression (since that contains just the global name t).

restart;

expr := t^2;

2
expr := t

p := t -> expr;

p := t -> expr

p(2.1);

2
t


This is a frequently asked question. Here are some ways to make it work. Note that :-t is a useful syntax for referring to the global name t, and distinguish it from a parameter or local name t.

expr := t^2;

2
expr := t

r := unapply(expr, t);

2
r := t -> t

r(2.1);

4.41

s := subs(dummy = expr, t->dummy);

2
s := t -> t

s(2.1);

4.41

w := t -> eval(expr, :-t = t);

w := t -> eval(expr, :-t = t)

w(2.1);

4.41

As you can see, unapply provides one convenient way to construct a procedure from an expression.

Try not to overuse unapply. It can be inefficient to have a procedure F that calls unapply each time you call F. Another way is to use 2-argument eval to evaluate an expression at a value for a name. Eg,

expr := sin(x)*exp(x):
eval(expr, x=2.1);
7.049114358


Also, never bother to create a procedure with unapply if you're only going to just call it with a name for its argument. You may as well just use the expression. Eg, here's something I see now and then,

restart;
expr := sin(x)*exp(x):

f := unapply(expr, x):
plot(f(x), x=0..Pi);   # this is silly, if it's the only time f is used.

plot(expr, x=0..Pi);   # one could just as easily do this
`

Also, don't try and use a function call on the left-hand-side of an assignment statement, unless you really know what you're doing. That was part of your original difficulty in your Question. That's complicated.

And so you could avoid the original problem simply by following the advice to not create a procedure (with some parameter name) and then only use it with a function call to the same unassigned name, or the advice to not assign to a function call.

 First 70 71 72 73 74 75 76 Last Page 72 of 424
﻿