## 29 Badges

15 years, 203 days

## like this?...

It isn't clear to me from your wording whether or not you want to avoid use of the mouse (eg. through context-panel actions).

One possibility is to use Equation Labels instead of assignment of the equation to temp names for equations and expressions. You might find that provides for doing "quick" and convenient substitutions in your worksheet, since there is a keyboard acceleration (Ctl-L) for inserting such references.

Or perhaps you are looking for a fully programmatic approach, with code that would work even in a commandline interface. For example,

```restart;

eq1 := a = 3*x+2*y;

eq1 := a = 3 x + 2 y

eval(eq1, [x=20,y=5]);

a = 70

eval(eq1, [x=5,y=1]);

a = 17

expr1 := 4*a-2*b;

expr1 := 4 a - 2 b

eval(eval(expr1, eq1), [x=5,y=1]);

68 - 2 b

eval(expr1, eq1);

12 x + 8 y - 2 b

eval(%, [x=5,y=1]);

68 - 2 b```

## placeholrder...

_Z is a placeholder for the solving-variable inside a RootOf implicit representation of a "root" of the system of equations.

You could try passing the explicit option to the solve command.

 > restart;
 > kernelopts(version); > eq3 := 2*lambda*(q+p*exp(t))*(q+p)^2*p*exp(t) = s:
 > eq4 := 2*lambda*(q+p)^2*(q+p*exp(u))*p*exp(u) = s:
 > solve({eq3, eq4}, {t, u}); > solve({eq3, eq4}, {t, u}, explicit); >

Download solve_ex1.mw

ps. Please don't post multiple Question threads for the same example and query.

## procedure from formula...

You can programmatically construct a procedure from the closed-form formula for the general sum.

```# general representation of the sum

general:=factor(sum((N+k)^2, k=0..N));

1
general := - N (N + 1) (14 N + 1)
6

# making a procedure from that formula

P:=unapply(general,N);

P := N -> (1/6)*N*(N+1)*(14*N+1)

P(10);

2585```
(In terms of run-time efficiency, this would be more suitable for the situation that you wanted to compute results for many concrete but differing integer values of N.)

## one way...

```a := {x = -12, y = -23}, {x = -34, y = 87},
{x = 18, y = 98}, {x = 27, y = 93},
{x = 45, y = 68}:

map2(op@eval,[x,y],[a]);

[-12, -23, -34, 87, 18, 98, 27, 93, 45, 68]```

## SetProperty, GetProperty...

The Do command from the DocumentTools module is merely an alternate access point for that module's GetProperty and SetProperty commands.

Those latter two commands are reasonable. Personally I find the syntax of the Do command to be poor. I always use GetProperty and SetProperty instead.

But all three of those commands relate to getting and setting the values of properties of Embedded Components that already exist in the current Worksheet/Document.

Does your sheet contain any Embedded Components (whether inserted manually from the Components palette, or in a Help page opened as working document, or programatically via InsertContent)?

There is currently no .mw file attached to your Question.

## evalf...

Get rid of the evalf calls, which produce floating-point results instead of the exact values.

I suspect you intended a seq call or similar (or perhaps your code snippet is inside some loop).

Eg,

seq( exp(2*Pi*I*i/3), i = 0 .. 2 );

## evaluation rules for procedure call...

That is not a bug.

The usual evaluation rules for a procedure call is that the passed arguments are evaluated before the procedure body computes. That is documented.

And so in your second example -- which produces the wrong plot -- you are actually passing the following to the plot command:

```f(n);

round(n)
1   (-1)
- + ------------
2      round(n)
n 2         ```

You have incurred an evaluation of f(n) prematurely, in your second example. That is user error, not a bug. It is similar to this effect,

```round(n) mod 2;

round(n)```

There are several ways to do it correctly. You could instead use irem instead of the mod command. You could utilize unevaluation quotes (as shown in your first example) to delay the evaluation of f(n). You could use the operator form calling sequence to the plot command. You could rewrite procedure f so that calling it with a nonnumeric argument would return that same function call unevaluated.

By the way, similar user difficulties arise frequently in Mathematica too, as can be seen in the many similar queries on https://mathematica.stackexchange.com in which ?NumericQ figures in answers.

## file name, as string...

Put quotation marks around the file reference (filename).

As you have it, it gets parsed as some invalid Maple statements. (In 2D Input the backslash gets parsed as minus, eg. for sets.)

## syntax...

Your attempt at using that command to set a new value is incorrect syntax. You could try it like so,

```kernelopts(includepath="C:\\Homes\\testFolder"):

kernelopts(includepath);

"C:\Homes\testFolder"```

That is similar to how kernelopts works for many other of its options.

(Note also that the return value is the previous value of the setting. I terminated that first statement with a full colon, so that aspect could be less confusing.)

## numeric error (eg. roundoff)...

Performing exact integration of an expression containing floating-point coefficients is a bad idea in general.

In your example the result contains an imaginary floating-point component due to numeric error (eg. roundoff error). That decreases with high enough working precision for the computation.

The real component also has numeric error, but of course you notice that less in the print-out.

The details vary a little according to the chosen method passed to exact int. (The choice method=contour can result in a purely real result for this example, but suffers from additional numeric error for the real component.)

Using indefinite integration or definite integration with unknown names for the end-points -- possibly along with conversion of float coefficients to exact rationals) one can obtain an expression whose imaginary component can be "simplified away". But the result from that may suffer from even more numeric error when the numeric end-points are finally unitlized.

A generally better choice is to perform purely numeric integration.

```f := -.5241663257+.6125225520*x-0.7468538250e-1*(2*x-3)^2
+0.1319812500e-1*(2*x-3)^3-sin(log(x)):

int(f^2, x = 1 .. 2, numeric);

-8
2.301629098 10  ```

Using Maple 17.02,  continuous_function_ac.mw

## method=ftocms...

```restart;

kernelopts(version);

Maple 17.02, X86 64 LINUX, Sep 5 2013, Build ID 872941

combine(int( sin(log(x+1)),x=-1..1,method=ftocms));

-cos(ln(2)) + sin(ln(2))```

And, for your followup file,

compute_integral_ac.mw

You can also apply FTOC yourself, using the indefinite integral and taking limits (using either limit or MultiSeries:-limit in your Maple 17, it seems).

## possible idea...

Did you try constructing the list entries as function calls, when using seq?

```restart;
alias(a1 = a1(r), a2 = a2(r), a3 = a3(r)):

array3 := [seq(cat(a, i)(r), i = 1 .. 3)];

diff(array3, r);```

A somewhat dubious alternative might be,

```restart;
alias(a1 = a1(r), a2 = a2(r), a3 = a3(r)):

array4 := [seq(parse(cat(a, i)), i = 1 .. 3)];

diff(array4, r);```

I find it difficult to be more precise in suggestions because I don't see an explanation of why you've chosen to use alias.

## alternative...

It is not necessary to store all the (possibly many and large) procedures generated by instantiating at different numeric values for parameter delta, in order to get decent speed-up by avoiding setting the parameter delta inefficiently.

That requires later clean-up (forget) for the memory to be cleared, and for some examples is an extra potential allocation issue. Such memory concerns and the use of advanced printf functionality are unnecessary for accomplishing this plotting task reasonably efficiently. The OP has made no request to store such procedures externally, and that's a pretty rare task.

Instead of the above, either name (here t or delta) can be put on the first axis in the 3D plot, while still getting the speedup of setting values efficiently for parameter delta. The parametric calling sequence of the plot3d command allows for parameter delta to be used more efficiently as the first ("outer") range, while still flexibly allowing either t,delta or delta,t being ascribed to axis,axis respectively.

This below is done in Maple 2017.3, since the OP was using that version a while back.

```restart;
phi:=0:lambda:=0.1:N:=5:M:=sqrt(N*(N+1))*exp(I*phi):omegap:=10:
var:={n(t),u(t),z(t)}:
dsys:={diff(n(t),t)=-2*(n(t)-N)+(u(t)-M)*exp(-2*I*omegap*t/lambda)
+((z(t)-conjugate(M))*exp(2*I*omegap*t/lambda)),
diff(u(t),t)=-2*(1-I*delta)*u(t)
+2*(n(t)-N)*exp(2*I*omegap*t/lambda)+2*M,
diff((z(t),t))=-2*(1+I*delta)*z(t)
+2*(n(t)-N)*exp(-2*I*omegap*t/lambda)
+2*conjugate(M)}:

res1:=dsolve(dsys union {n(0)=0,u(0)=0,z(0)=0},
numeric, parameters=[delta], output=listprocedure):

Nt:=eval(n(t),res1):

Ntd:=proc(t,delta)
if not [args]::list(numeric) then 'procname'(args);
else
if rhs~(Nt(parameters))<>[delta] then
Nt(parameters=[delta]);
end if;
Nt(t);
end if;
end proc:

CodeTools:-Usage(plot3d([t, delta, Ntd(t,delta)],
delta=-10..10, t=0..1, axes=boxed));
memory used=8.44GiB, alloc change=36.00MiB, cpu time=64.89s,
real time=64.91s, gc time=5.06s``` ```CodeTools:-Usage(plot(Ntd(.5,delta), delta=-10..10,
numpoints=49, adaptive=false));
memory used=4.66GiB, alloc change=80.00MiB, cpu time=35.69s,
real time=34.11s, gc time=3.65s``` I wrote the above for Maple 2017.2, but in Maple 2019.2 (and later) some improvement to dsolve's runtime parameter handling allows for even simpler and more understandable code. The conditional test to check whether the parameter value has changed is no longer needed above in order to get the speedup from that use of the parametric call to plot3d. So the following is enough, paring it down while keeping it understandable (IMNSHO):

```phi:=0:lambda:=0.1:N:=5:M:=sqrt(N*(N+1))*exp(I*phi):omegap:=10:
dsys:={diff(n(t),t)=-2*(n(t)-N)+(u(t)-M)*exp(-2*I*omegap*t/lambda)
+((z(t)-conjugate(M))*exp(2*I*omegap*t/lambda)),
diff(u(t),t)=-2*(1-I*delta)*u(t)
+2*(n(t)-N)*exp(2*I*omegap*t/lambda)+2*M,
diff((z(t),t))=-2*(1+I*delta)*z(t)
+2*(n(t)-N)*exp(-2*I*omegap*t/lambda)
+2*conjugate(M)}:

res1:=dsolve(dsys union {n(0)=0,u(0)=0,z(0)=0},
numeric, parameters=[delta], output=listprocedure):
Nt:=eval(n(t),res1):
Ntd:=proc(t,delta) Nt(parameters=[delta]); Nt(t); end proc:
plot3d([t, delta, 'Ntd'(t,delta)], delta=-10..10, t=0..1);```

## style=line...

It's not clear whether you want the dashed line segments.

But, instead of shading=none and transparency=1 perhaps you are looking for the effect from style=line and color=black, for the cuboid.

For example,

```fig1:=plots:-textplot3d([[0, 0, 0, "B", 'align' = '{below, left}'],
[0, 0, 1, "A", 'align' = '{above, left}'],
[0, 1, 0, "C", 'align' = '{below, right}'],
[0, 1, 1, "D", 'align' = '{right}'],
[1, 0, 0, "F", 'align' = '{left}'],
[1, 0, 1, "E", 'align' = '{above, left}'],
[1, 1, 0, "G", 'align' = '{below, right}'],
[1, 1, 1, "H", 'align' = '{above, right}']],
'font' = ["times", "roman", 20], 'color' = "Red"):

fig2:=plottools:-cuboid([0, 0, 0], [1, 1, 1],
style = line, color = black):

plots:-display([fig1, fig2], axes = none, size = [350, 350],
orientation = [179, 15, 165]);``` ## is, simplify...

Your two expressions are not always equal.

```restart;

kernelopts(version);

Maple 2021.0, X86 64 LINUX, Mar 5 2021, Build ID 1523359

f__1 := sqrt(4*a^2 + lambda__g^2)*c/(2*lambda__g*a):

f__2 := c*sqrt(1/lambda__g^2 + 1/(4*a^2)):

simplify(f__1-f__2) assuming lambda__g>0, a>0;

0

simplify(f__1-f__2) assuming lambda__g<0, a<0;

0

combine(simplify(f__1-f__2)) assuming real, lambda__g*a>0;

0

is(f__1-f__2=0) assuming real, lambda__g*a>0;

true

# example where not equal
eval([f__1, f__2], [lambda__g=-1, a=1, c=1]);

[  1  (1/2)  1  (1/2)]
[- - 5     , - 5     ]
[  2         2       ]
```
 1 2 3 4 5 6 7 Last Page 1 of 246
﻿