5259 Reputation

17 Badges

7 years, 111 days

MaplePrimes Activity

These are replies submitted by mmcdara

... I will look at your problem on Thursday when I am teleworking (I looked at it and it will take me some time to work out an answer).

BTW, I saw errors in my original worksheet ;-(

@Kitonum  @C_R

The term within the parenthesis is not of the form required by the OP

Maple 2015  returns the closed form of this integral whatever the input mode (which both behave the same way)

@Carl Love 

I use the combinat package on regular basis but randcom never caught my eye.


I didn't know about _EnvUseHeavisideAsUnitStep, whose role is nevertheless clearly stated in Heavside's help page.

It indeed can be a usefull way to remove isolated points where the expression is undefined, but don't you think it's quite dangerous is used blindly?

Here is an example which describes the Coulomb's static friction model.
The piecewise function represents a physically correct model  (while extremely notional) of the variation of the friction coefficient c according to the relative slipping velocity at the contact point of two bodies.

f := piecewise(v < 0, -c, v=0, 0, v > 0, c)
            piecewise(v < 0, -c, v = 0, 0, 0 < v, c)

_EnvUseHeavisideAsUnitStep := false; 
convert(f, Heaviside); 
eval(%, v=0);
                      2 c Heaviside(v) - c
                        c undefined - c

_EnvUseHeavisideAsUnitStep := true; 
convert(f, Heaviside);
eval(%, v=0);
                      2 c Heaviside(v) - c

I do prefer the default _EnvUseHeavisideAsUnitStep := false which warns me that there will probablity face later some difficulties, than  _EnvUseHeavisideAsUnitStep := true which seems to say that there will be no problem at all and provides a wrong value at v=0.

For information the numerical treatment of problems invoking this Coulomb's model generally regularize the expression f by writting instead f := c*tanh(v/eps) where eps is a "small" positive number.

For the OP problem I believe that the first thing do do before removing the isolated points where the onverse Laplace transform i undefined, is to check if the left and rightlimites are equal (which happily happens to be the case here).

y := inttrans:-invlaplace(expr,s,t):

limit(y, t=Pi, left), limit(y, t=Pi, right);
                              0, 0

limit(y, t=2*Pi, left), limit(y, t=2*Pi, right);
                    1 + exp(Pi)  1 + exp(Pi)
                    -----------, -----------
                     2 exp(Pi)    2 exp(Pi) 

I nevertheless vote up: for the simplicity of the trtick, even if I'm not convinced of its lack of toxicity


It's difficult to admit that Statistics:-AutoCorrelation and Statistics:-CrossCorrelation don't have consistent definitions (the former operates on a mean-shifted vector while the latter works with raw vectors) given that CrossCorr(V, V= = AutoCor(V) by definition.

I keep considering this inconsistency as an error of the same order than a confusion between moments and non centered moments.
But you are free to think otherwise.


You wrongly interpreted what you read here
You confused autocorrelation function and autocovariance function.


Here is your file corrected
Please look to the parameters q__E (and not q[E]) and sv0 (shich appears as s__v*0 in 1D input).

in dsolve the option parameters requires a list of names, but in the "instanciation" of the solution (solparameters requires a list of values.
An alternative which avoids using the option parameters during the "instanciation"  is given  at the end of my reply.

@Carl Love 

Thank you Carl for this extremely interesting (ordered) set of explanations.

About point 4
The --setsort entry contains a lot of useful informations.
In particular the example s := {bb, aaaaaaaa} whose displayed order ("internal memory order " too?) is based on the length of the elements.
The --setsort option seems to be only avaliable through the Maple command mode, am I right?
Unlesswritting sort(convert(s, list), lexorder), would have been a way to impose the lex order on the set s?

About point 5:
I do remember sets ordered in a different way from one session to another. I even think this "nuisance" lasted a little bit longer than Maple 8.

About point 6:
I agreee.

The problem I submitted comes from the transformation of a system of ODEs of arbitrary orders into a system of first order ODEs alone.
The selection of the dependent functions (F) and the derivatives through which they intervene (DF) is descibed below (the system comes from a recent question on this site).
My algorithm to transform this system into a first order ODE system starts from the rightmost element of each set in DF an ends to the leftmost one, inrtoducing intermediate functions at each move.
But it didn't work due to the different "true" orders (by opposition to the "displaying orders") of each of these sets.
(I did otherwise meanwhile)


odeSys := {diff(Theta(x), x, x)+Pr*(R*(diff(Theta(x), x))*f(x)+Nb*(diff(Theta(x), x))*(diff(Phi(x), x))+Nt*(diff(Theta(x), x))^2), N2*(diff(G(x), x, x))-N1*(2*G(x)+diff(f(x), x, x))-N3*R*((diff(f(x), x))*G(x)-f(x)*(diff(G(x), x))), diff(Phi(x), x, x)+R*Sc*f(x)*(diff(Phi(x), x))+Nt*(diff(Theta(x), x, x))/Nb, (1+N1)*(diff(g(x), x, x))+R*((diff(g(x), x))*f(x)-g(x)*(diff(f(x), x)))-M*g(x)+2*Kr*(diff(f(x), x)), (1+N1)*(diff(f(x), x, x, x, x))-R*((diff(f(x), x))*(diff(f(x), x, x))-f(x)*(diff(f(x), x, x, x)))+N1*(diff(G(x), x, x))-M*(diff(f(x), x, x))-2*Kr*(diff(g(x), x))}:

# print~(odeSys):

DF0, F := selectremove(has, indets(odeSys, function), diff):
DF     := convert(map(u -> select(has, DF0, u), F), list):

{G(x), Phi(x), Theta(x), f(x), g(x)}



{diff(G(x), x), diff(diff(G(x), x), x)}


{diff(Phi(x), x), diff(diff(Phi(x), x), x)}


{diff(Theta(x), x), diff(diff(Theta(x), x), x)}


{diff(diff(g(x), x), x), diff(g(x), x)}


{diff(diff(diff(diff(f(x), x), x), x), x), diff(diff(diff(f(x), x), x), x), diff(diff(f(x), x), x), diff(f(x), x)}






@Carl Love 

Thank you Carl.


The reason is probably the word "+" in the file name, try this one and let me know.

I advise you to start by searching for the word homotopy on this site.
You will probably find some interesting things.

I think if you want someone to help you, you should provide a Maple code instead of an excerpt from a PDF file that nobody here is willing to code themselves.


Both @tomleslie and I have already answered the same thing to a previous question
It seems that @JAMET ​ does not read the answers it's been provided.


I also notice, as @tomleslie pointed out recently, that yours questions never provide any worksheet, a remark that obviously did not change your attitude..
I find this latter contemptuous and would personally make it a point to never respond to you again.


By the way, it happens that one of the best book ever (IMO) on data mining, inference and prediction is freely avaliable:

In my paper version Chapter 13 is entirely devoted to Nearest-Neighbors methods.
Several algorithms (sometimes in pseudo code are provided too).

PCR is described in pp 79-80, PLS in pp 80-82 and, more generaly, regression methods in Chapter 3.

First 14 15 16 17 18 19 20 Last Page 16 of 113