Preben Alsholm

11754 Reputation

22 Badges

15 years, 305 days

MaplePrimes Activity

These are replies submitted by Preben Alsholm

@Kitonum Yes, it was introduced in Maple 2019.

@666 jvbasha Notice that in R_init T comes first, then diff(T(eta),eta), then f(eta), etc.

Thus use the order:
H, H1, F, F1, F2, G, G1, G2 := op(rhs~(R_init[2 .. -1]));

and everything else is fine.

@Alger What do you mean by saying that " Variables of the model should be null when C<40e-6 and can be not null when C>40e-6 with imposing high range." ?

Do you mean that for C <40e-6 all the dependent variables (like e.g. ids(t))  go to zero as t -> infinity?

And for C>40e-6 they tend to a periodic solution (not identically 0)?

@Alger I had another look at your system. Although it starts out looking linear it ends up being highly nonlinear. Thus there isn't any a priori reason to deny the actual existence of singularities.

The "singularity" problem I ran into with C = 0.000050 and range 0..50 disappeared, however, when I used your original equations eq1, eq2, eq3, and eq4 together with ep5 and ep6.

Unfortunately, for C = 0.000045 and range 0..100 I still got a "singularity" at the same point you got one.

There are obvious numerical difficulties with this problem, so I'm still not convinced that a genuine singularity is present.

Here is the revised worksheet:

@Alger When dsolve/numeric talks about a probable singularity one should (as you surely do) notice the adjective "probable".

What exactly is a singularity in this numerical context? What triggers the error (or warning) message?
Your system is very complicated, so it isn't easy to see. It would be nice to find a simpler example with the same problem.

@Alger You get a similar complaint when keeping C at 0.000050 but changing the range from 0..40 to 0..50:

Warning, cannot evaluate the solution further right of 47.288331, probably a singularity.


@arashghgood You ask in the title " Is there a solution?".

Clearly without additional requirements there are the very trivial solutions f(x,y,t) = F1(t)*y+F2(t) , (where F1 and F2 are arbitrary).

But I have no idea about how to solve this type of problem numerically.

You could set infolevel[int]:=5:

integrand1 := (x^3*exp(arcsin(x)))/sqrt(1 - x^2);
integrand2 := (x^3*exp(1)^arcsin(x))/sqrt(1 - x^2);


The first 4 steps are the same, but then they. Obviously the choice of approach is governed by the integrand and they are different.

exp(arcsin(x)) is of type function and exp(1)^arcsin(x) is of type `^` .

@acer Your solution is obviously simpler, but I was about to give this answer:
Wrap the last block of assignment code in a procedure call with SF declared global:

proc() global SF; 
  ['('Par')', '('add_basis')', '('char2sf')', '('conjugate')',
   '('dominate')', '('dual_basis')', '('evalsf')', '('hooks')',
   '('itensor')', '('jt_matrix')', '('nextPar')', '('omega')',
   '('plethysm')', '('scalar')', '('sf2char')', '('skew')', '('stdeg')',
   '('subPar')', '('theta')', '('toe')', '('toh')', '('top')',
   '('tos')', '('varset')', '('zee')'])
end proc();


@Anthrazit Have you tried my Round procedure?

If so, any comments?

Using an old procedure of mine (chop) I made up the following procedure Round which uses chop.
This combination is very likely unnecessarily clumsy and also not perfect otherwise.

Since, however, my computer is going to a repair shop for booting problems this morning, I dare give the code here with only a few examples.

chop:=proc (x::anything, n::nonnegint:=0) local op1, op2, k; 
   if not hastype(x,float) then return x end if; 
   if x::float then
     if n=0 then return round(x) end if; 
     op1, op2 := op(x); 
     k := length(op1); 
   end if 
end proc:
Round:=proc(x::anything,d::nonnegint:=0) local tr,fr,L,res;
  if not hastype(x,{realcons,complexcons}) then return x end if;
  if x::float or x::integer then 
  elif x::realcons then
  elif x::complexcons then
  end if;
end proc:


What should acer's Round(123456,2) return in your opinion?

@mmcdara There are in fact no imaginary parts. Those that do turn up after using evalf are artifacts of the floating point computation.

Try evalc(Im(EPS)) and also evalc(Re(EPS)) and you will see that Maple knows that Kummer functions in use are actually real. For perfect zeros in the first case (Im) it is important that the initial values are cleared of the small imaginary "artifacts".

An alternative is to avoid floats as in:


and the other ones in the same way. It works, but the drawback is a builtup of huge symbolic expressions.

dsolve does indeed turn floats into rationals:


That has always been done in Maple at least as far as back to Maple 8 (the oldest on this computer).
This is definitely done purposely. I vaguely remember a discussion raised by somebody about that on MaplePrimes and that Edgardo Cheb-Terrab defended that handling.

@Carl Love Indeed weird with that number 10.

I do see that `limit/MrvRight` (called several times) in line 11 has the statement:

 if 10 <= nops(`limit/IndetsRange`(t)) then
        return _Range
 end if;

Whether that has anything to do with the importance of 10 I have no clue so far.

If you replace limit by MultiSeries:-limit you get 1.

I0:=(x - 11)^(n)*x/(x^(n + 1));                                              
I1:=(x - 11)^(n)/(x^(n));                                                    
Limit(I0,x=infinity)=MultiSeries:-limit(I0,x=infinity) assuming n::posint;
Limit(I1,x=infinity)=MultiSeries:-limit(I1,x=infinity) assuming n::posint;    
### Carl's example:
MultiSeries:-limit((x-a)^n*x/x^(n+1), x= infinity) assuming n::posint, a>10;
MultiSeries:-limit((x-a)^n*x/x^(n+1), x= infinity) assuming n::posint, a<10;


4 5 6 7 8 9 10 Last Page 6 of 204