Preben Alsholm

13491 Reputation

22 Badges

19 years, 138 days

MaplePrimes Activity


These are replies submitted by Preben Alsholm

@fnavarro It is a really bad idea to use plot as a toy model.
As dharr is pointing out there is nothing wrong with evaluation, but plot is rather special for the reasons I mentioned.
Take a look at this code.

restart;
Digits:=40:
E:=x*exp(-x);
V:=Vector([seq](evalf(eval(E,x=i)),i=0..20));
max(V); # 0.3678794411714423215955237701614608674458
min(V); # 0.

@sand15 There is some confusion: You write to begin with:
"But it seems that test and `test` do not mean exactly the same thing here:",

but you use unevaluation quotes in select(type, {anames()}, suffixed('test'));

When test:=0 (or assigned to anything else)  'test'; first evaluates to test, then to 0.
 

restart;
test:=47;
'test'; # test
%; # 47
## In contrast:
`test`; # 47


 

@Carl Love Yes, although ? keywords brings up a help page with the title
Maple Keywords (Reserved Words).

Furthermore the statement really refers to symbols:

type(sin,symbol); #true
type(Pi,symbol);  #true
evalb(`sin`=sin); #true
evalb(`a[1]`=a[1]);  #false
type(`a[1]`,symbol); #true
type(a[1],symbol);   # false
type(a[1],name);     #true

 

@Carl Love It could be pointed out that in these examples the same holds:

`sin`(Pi/3); # 1/2*sqrt(3)
`exp`(ln(x)); # x
sin(`Pi`/3); # 1/2*sqrt(3)
Pi:=6; # Error

The attempt to assign to Pi results in the error:
Error, attempting to assign to `Pi` which is protected.  Try declaring `local Pi`; see ?protect for details.

Similar errors follow attempts to assign to sin or exp.

In the help page ? names we find this statement:

Any valid Maple name formed without using left single quotes is precisely the same as the name formed by surrounding the name with left single quotes.  Therefore, x and `x` both refer to the same name x. However, a keyword cannot be used as a name unless it is enclosed in left single quotes.

 

@Axel Vogt You didn't imply that your analysis shows an error and there isn't any.
Since B > 0, A+B*s will be positive if just s is large enough. It is correct that A < 0 under the assumptions.
The requirement is s > -A/B and that is exactly the same as returned by solve in my res[6].
In detail:
 

restart;
Q:=(a - c)^2*y*(3*b*y - 1)/(2*(2*b*y - 1)^2) + 
  (-a*(a + c)/(2*b) + (a - c)^2/(8*b) + s*(a - c)^2/(8*b^2));

theAssumptions:=(2*c < a, a/c < 2*b*y, 0 < a, 0 < b, 0 < c, 0 < s, 0 < y); 

A:=coeff(Q,s,0);

B:=coeff(Q,s,1); # Obviously positive

is(A < 0) assuming theAssumptions; # true

#The requirement for s being positive is:
sol:=s > -A/B; # -A/B is positive

#The result that I found using solve with the assumptions were (in your notation):
res:=solve(Q>0,useassumptions) assuming theAssumptions;

res6:=simplify(res[6]);
simplify(lhs(sol)-lhs(res6)); # 0

 

@Axel Vogt Note: I edited this comment.

Yes, s>1 is required, and that follows the result res[6]:

#Using my notation and your example:
eval(res[1..5],[a = 103/49 + sqrt(25776)/98, b=1/4,c=1, y=8]);
is~(%); # {true}
simplify(res[6]);
simplify(eval(%,[a = 103/49 + sqrt(25776)/98, b=1/4,c=1, y=8])); # 1<s

 

@Hahn Hahn If you look at the help page, which explains the workings of is (do ?is), you will see this:

"The is routine determines whether the given proposition is satisfied. It returns true, false, or FAIL.
....
The is function returns FAIL if it cannot determine whether the proposition is always satisfied. This is a result of insufficient information or an inability to compute the logical derivation."

Thus it will not give you conditions, but solve will:

restart;
expr:=(a - c)^2*y*(3*b*y - 1)/(2*(2*b*y - 1)^2) + (-a*(a + c)/(2*b) + (a - c)^2/(8*b) + s*(a - c)^2/(8*b^2));
sol:=solve(expr > 0);

You could also try solve with your assumptions:
 

res:=solve(expr>0,useassumptions) assuming 2*c < a, a/c < 2*b*y, 0 < a, 0 < b, 0 < c, 0 < s, 0 < y;

You will get 3 warnings, but a warning isn't an error!
The result res has 6 conditions: The first 5 are simple:

res[1..5];
## {0 < b, 0 < c, a < 2*c*y*b, 1/b < y, 2*c < a}

The last res[6] is long so I will not give it here.
It can be simplified, however, but is still big.
 

simplify(res[6]);

You will see that the denominator on the left side of the inequality is positive. The right hand side is just s. Thus as long as the simple conditions res[1..5] are satisfied, condition res[6] is satisfied if just s is large enough.

@Hahn Hahn Could you please upload a worksheet?

@mmcdara I would replace Pi and sqrt(2) by evalf(Pi) and sqrt(2.), respectfully.
Then I don't get any errors of any kind in running your worksheet.

I use kernelopts(floatPi=false). If you use the default, which is floatPi=true, you may not need the first replacement;
you will, however, need the second.

Using allvalues as Axel Vogt suggested, but also add, which is suited for adding finite sums:

restart;
ode:=diff(y(x),x) = (x*y(x)+x^3+x*y(x)^2+y(x)^3)/x^2;

rts:=[allvalues(RootOf(27*_Z^3-9*_Z+29))];
sol:=exp(3*add(1/(9*j^2-1)*ln((-j*x+y(x)-1/3*x)/x),j = rts))-c__1*exp(x) = 0;

indets(sol,function(name));
#odetest(sol,ode); # Does it ever finish?

ode2:=diff(u(x),x)-1/2*(2*a*u(x)^3+u(x)+2*b)/x = 0;

rts2:=[allvalues(RootOf(2*_Z^3*a+_Z+2*b))];
sol2:=2*add(1/(6*j^2*a+1)*ln(u(x)-j),j =rts )-1/2*ln(x)-_C1 = 0;

indets(sol2,function(name));
#odetest(sol2,ode2); # Does it ever finish?

No complaint when actually trying odetest. 
Your original version run in Maple 2024 Beta has the same error when using odetest:

Error, (in simplify/RootOf) too many levels of recursion
One might prefer that error message to a process that runs forever.

@sand15 It doesn't work in Maple 2023.2, but works in Maple 2024.0 Beta.

That said, I think it is better to use add than sum in cases where the limits are numeric values.
In the present case I'm assuming that S(N,x) will only be applied if N is of type numeric.

You are first making assumptions on a sequence of names (about them being real).
Then in the next line you are again making assumptions about those names, this time involving inequalities.
The first assumptions are wiped out totally by the second, but in your case your second assumptions, being inequalities, imply that the names are assumed real.
Try about(gamma); after the second assume.
Then try commenting out the first assume, and then run the lines from restart to 'about'.
The about(gamma) message is in both cases:

Originally gamma, renamed gamma~:
  is assumed to be: RealRange(0,infinity)

See ?assume, where you will find the following lines:

When the assume function is used to make an assumption about an expression x, all previous assumptions on x are removed. For example, if you enter assume(x>0) then assume(x<0), there is no contradiction.  Similarly, assume(0<x) followed by assume(x<1) is not equivalent to assume(0<x, x<1).

 

@mmcdara Thanks for your explanation. I think I understand your situation.

I will here give some rather arbitrary examples of algebraic expressions where the same integral appears several times, but with different names for the integration variable.

restart;
J1:=Int(f(x),x=0..1)/Int(f(y),y=0..1);
simplify(J1);
J2:=sin(Int(f(x1),x1=0..1))/Int(f(y1),y1=0..1);
simplify(J2);
J3:=G(Int(f(x2),x2=0..1))/H(Int(f(y2),y2=0..1));
simplify(J3);
J1*J2*sqrt(J3);
simplify(%); 
inds:=indets(J1*J2*sqrt(J3),specfunc(Int));
simplify(inds); # No change. inds is a set, so not of type algebraic 

My guess is that in code handling algebraic expressions involving several integrals that are actually equal except for appearance, it could save time because only one integral need be computed.

PS. I'm glad that a name like you mention _t123 is not introduced.

@Carl Love It is good to have other options. I prefer 'thistype' though.

@dharr I guess that kencom1 uses inf as a substitute for infinity.
For inf:=3
odeplot(S1,[y,u[1](y)],0..inf); 
gives us:

and for inf:=10 we get:

Thus kencom1 has more work to do.

3 4 5 6 7 8 9 Last Page 5 of 226