@Mariusz Iwaniuk 

Hi again, (sand15 at home = mmcdara)

Here is the corrected Voltera2.mw

Volterra2bis.mw

 

@rlopez 

Right, this is very likely the expression of arc length in polar coordinates.
So I wonder how this arc could take negative values for some ranges of phi (as the plot suggests)?
More of this LL(phi+dphi) > LL(phi) provided dphi > 0.
As you said it would be interesting to have the expression of rho(theta).

But I think that is here a "plot" problem: considering the arc length must be positive, I suggest that the plot in the "visual" range 1.5..3 (more likely Pi/2..Pi) is wrong and could be vertically translated by about 2*0.8.
It it was so, the curve would be continuous and it's value LL(3) would be "braphically" around 1.68...

@maple2015 

You should downgrade me for MapleMathMatt gave a prettier answer than I did !!!

@MapleMathMatt 

Excellent remark.
​​​​​​​Here is the someone who delivers the astute answer I talked about in my first reply...

@ The computational time for your loop 
for i from 1 to nn+1 by 1 do
...
end do

is about 0.13 s (Maple 2015.2, iMac 2.9GHx Intel Core i5), which doesn't seem to be a huge computational time.

More of this, this same loop contains the line
        ics:=sv(H-He)=sve,sh(H-He)=she,Lambda(H-He)=Le,u(0)=0,Jir(H-He)=Jire:
shouldn't it be
        ics:=sv(H-He)=sve,sh(H-He)=she,Lambda(H-He)=Le,u(H-He)=0,Jir(H-He)=Jire:
???

@maple2015 

To complete my last reply:
Change proc(M::Matrix, n::numeric)  by proc(M::Matrix, n::{numeric, symbol}) 

Suppose M := `<|>`(`<,>`(1, c, 2), `<,>`(4, 1, c)).
Then 
Find(M,c);
                        {[2, 1], [3, 2]}

@maple2015 

You could also be interested in this one:

Find := proc(M::Matrix, n::numeric) 
  local S, T:
  S := op(2, M);
  T := map(u -> rhs(u)=[lhs(u)], S);
  map(u -> if lhs(u)=n then rhs(u) end if, T); 
  end proc:


Find(M,3);
                        {[2, 1], [3, 2]}
Find(M,8)
                               {}

Add on

HugeF.mw

@Carl Love 

Let us suppose you are a teacher and you ask some student to solve an equation by hand.

Your student does the exercise and gives you the expressions of all the roots he hound.

   You             : « have you checked your solution ?» 
   The student: « No, but I’m very confident in the method I used to find it »
   You             : « I have no doubt about that, but without checking your solution is worthless »

Now you are still the teacher and the student has name Maple.
If Mr Maple has not checked its solution, then the latter is worthless.

If you consider, and I can follow you blindly on this point, that a solution has to be checked before to be delivered,
than you should admit that Mr Maple has done only a part of the job.

So, to illustrate that Maple doesn't always (?) check the roots, here are the results obtained on a slight variant of your toy example The function I want to find the roots when a=1 is  f := a -> sqrt(x) - sqrt(a-x) - 1.
You will see that  solve(f(1), x)  and subs(a=1, [solve(f(a), x)]) do not provide the same results.
The second command has an extraneous solution Maple should have discarded had it have correctly done the job

reply.mw

Up to some extent I don't care of the inner algorithms or algebra Maple uses: if Maple returns a result it has to be verified, and if it doesn't it has to say it has failed (which is generally what happens).
When I have bought my Maple license I have also bought this, this trust or faith in the answers Maple returns.

 

I had found very peremptory and rude Mariusz’ sentence « I can only say that the Maple contains a huge amount of bugs, with cause that we can't trust the results. » (see his last reply on this same thread).
But your patronizing attitude to try and show me that I just don’t understand (a thing I’m not at all ashamed to admit)
is not sufficient to keep me convincing that Mariusz is wrong.

I have much respect for you and for the job you are doing here.
So, before the situation gets toxic, I will quote Mariusz on this same thread by saying  "this is my final answer"


Thanks for your contribution

@Carl Love 

I agree with your last reply
"Call this Eq2. By the definition of function, any solution of Eq1 is also a solution of Eq2. But the converse is not necessarily true! For example, if h = y -> y^2 and there is an c such that f(c) = -1 and g(c) = 1, then x = c is a solution of Eq2 but not of Eq1."

If you refer here to the substitution _Z=U^(1/5) I used, you're perfectly right: this "h" function is non-injective on (f(A) intersection g(A)).
It seems that the substitution _Z=surd(U,5) would have been the good one to apply ... unfortunately some problems still remain


But I think the core of my turmoil is not here and that I did not explained myself well when I asked you
"is it something proper to Maple (or any other CAS) or is it a mathematical result?".

So, no offence, you only partially answered my "subliminal" question which, in essence, can be expressed this way:

• Let f  some function of r, M and lambda.
   
• First approach:
  • You solve f(r, M, lambda) -1 = 0 with respect to r
  • You substitute M=1 and lambda=1 in the solution (a single RootOf)
  • You apply allvalues, next evalf, and finally select the only roots with an imaginary part less than 10^(Digits-2)
    (reasonnably real roots)
    The result contains four roots A, B, C, D
     
• Second approach:
  • You substitute M=1 and lambda=1 in the equation f(r, M, lambda) -1 = 0 
  • You solve this equation with respect to r (yet the solution differs from the  single RootOf of the first approach)
  • You apply allvalues, next evalf, and finally select the only roots with an imaginary part less than 10^(Digits-2)
    (reasonnably real roots)
    The result contains only the roots A, B

Why do the two approaches give different results ?
(there is no "h" function here, unless hidden)

Approach 1 returns two spurious roots (C and D) which, once injected in f(r, 1, 1) -1, eval to "2" and not "0"

When you first said "As is very well known, that process has the risk of introducing extraneous solutions", I thought you were referring to the fact that instanciating parameters (here M and lambda) before or after applyinf solve could introduce extraneous solution!

Certainly I was by no means clear.
In the attached file you will find the the ccomplete calculations for those two approaches, where f is the original function provided by mhdlynch.

Still_not_clear.mw

@Carl Love 

Very kind of you to have taken a little time to look at my worksheet !
(and sorry for my late reply)

When you write "As is very well known, that process has the risk of introducing extraneous solutions": is it something proper to Maple (or any other CAS) or is it a mathematical result?
In any case I have correctly understood that the solutions "need to be verified in the original equation".



 

@Mariusz Iwaniuk 

I'm sure you're right !
I'm sure too that I got stucked by something I can't put my finger on.

Could you be kind enough to take a look to the attached file?

I compare your approach to mine's: at some point Maple doesn't return (apparently) the same results (commans in red with yellow background).
In my answer to mhdlynch I used the transformation U=r^5 which leads to a 4th order polynomial equation (M and lambda where not assigned to any value).

The method I used in this post returns 4 real "U roots" (all different) and then 4 "r roots" assuming r is real.
In the last part of the attached file these last roots are computed in two different ways ("^(1/5)" and surd(.., 5)) and I get two different sets of values.
At this point I cannot understant it !!!

I guess an external eye is necessary to show me where my mistake is 

NeedHelp.mw

@Mariusz Iwaniuk 

Is I'm not mistaken you do not solve the correct problem
 

f := 1+r^2*(1-sqrt(1+20*lambda*M/r^5))/(6*lambda);
func := eval(simplify(lambda*(2*(diff(f, r, r))+4*(diff(f, r))/r)-1), [M = 1, lambda = 1]);

# having written lambda*(2*(diff(f, r, r))+4*(diff(f, r))/r)-1  you must solve func=0, not func=1 (what you did probably given the roots you obtained)

# simpler if we do this transform :

Ufunc := subs(r=U^(1/5), func);

subs({M = 1, lambda = 1}, Ufunc);
solve(%=0,U);
op([2,1], %[1]);
RootFinding:-Isolate(%);

@Mariusz Iwaniuk 

Hi, we have had the same idea.
I think we can go a little bit further (look my file in my reply to mhdlynch).
Furthermore I don't think MMA provides the good solution.
If I'm not mistaken it should be 
] -2.217533520, -2.040737917 [   union   ] 0.6124468982, 1.177609717 [

@litun 

Thank you for the info