## 13613 Reputation

19 years, 239 days

## MaplePrimes Activity

### These are questions asked by Preben Alsholm

MaplePrimes

I have noticed that I don't receive e-mails anymore when contributions are submitted to my subscriptions.
I used to.
Has this happened to anyone else?

It is embarrasing to have asked somebody a question and gotten a reply you are not made aware of.

## Is there an example where the NO_INT opt...

Maple

In the help page for invlaplace we find the statement
"If the option opt is set to 'NO_INT', then the program will not resort to integration of the original problem if all other methods fail.  This will increase the speed at which the transform will run."

This statement is found in Maple 2017 and in Maple 8 and I believe in all versions in between.
Can anyone provide an example of a function F(s), where
invlaplace( F(s) ,s, t, NO_INT);
gives a different result (or works faster) than
invlaplace( F(s) ,s, t);
?
## It should be added that an identical statement is made in the help page for laplace itself.

## Spam titles with http...

MaplePrimes

Couldn't any question with title beginning with http be removed automatically? There has been quite a few containing nothing but spam.

## Undesired expansion in solving...

Maple 2016

In working on an answer to a recent question on MaplePrimes:
http://mapleprimes.com/questions/210948-Can-We-Trust-Maple

I noticed that in solving a "simple" system of two equations in two unknowns, potentially undesirable expansion occurs.
The two equations were only simple in the sense that the solving was very trivial, since the two unknowns occurred (almost) already isolated on the left:
eq1:=diff(x(t),t)=rhs1;
eq2:=1.2345*diff(v(t),t)=rhs2; #rhs2 is very complicated in the link given.
So in isolating I tried:
solve({eq1,eq2},{diff(x(t),t),diff(v(t),t)});
The resulting ode system took considerably longer to solve numerically than an unexpanded version.
It is trivial (of course) to do the solving without solve in this case.

Here is an extremely simple example, where the unknowns are already isolated, so that the equations themselves are actually the solution.

restart;
eq1:=a=b*(c+d);
solve(eq1,a); #No expansion
eq2:=e=b*(c+d)+f*(8+k);
solve({eq1,eq2},{a,e}); #Expanded:
{a = b*c+b*d, e = b*c+b*d+f*k+8*f}

Can expansion be avoided?

## What does assume n=7 mean?...

Maple

The question in the title has been raised before over the years, but has maybe not received enough attention.
Reraising the question was motivated by a comment by Kitonum to a recent post on improved integration results in Maple 2016:
http://mapleprimes.com/maplesoftblog/202910-New-And-Improved-Integration-Results

Consider the following session.
restart;
assume(n=0);
n^2; #Returns n^2
eval(%);#Returns n^2
sin(n*Pi); # Returns 0
sin(n); # Returns sin(n)
eval(%); # Returns sin(n)
ln(n); #Returns ln(n)
ln(n*exp(1)); # Returns ln(n*exp(1))
expand(%); # Error, (in ln) numeric exception: division by zero
ln((n+1)*exp(1)); Returns ln((n+1)*exp(1))
expand(%); # Returns ln(n+1)+1
sqrt(n^2); # Returns 0
sqrt(n); # Returns n^(1/2)
eval(%,n=n^2); # Returns (n^2)^(1/2)
simplify(%); #Returns 0: simplify doesn't help in the examples above.
##################
We see that assume n=0 certainly doesn't imply that expressions always will be evaluated at n=0, but sometimes it appears that it does.
So what is the intended behavior when assuming equality?
##
Several years ago (Maple 14 or earlier) I overloaded assuming so that equality assumptions were handled by eval.