Carl Love

Carl Love

28025 Reputation

25 Badges

12 years, 311 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

Assuming that I'm correct about the corrections that need to be made to the algorithm, as noted in my Reply above, then a translation of the algorithm into Maple is

Paar:= proc(M::Matrix)
local H, R:= copy(M), maxij, newcol;
     do
          maxij:= [max[index]((H:= rtable(antisymmetric, R^+.R)))];
          if H[maxij[]] <= 1 then return R fi;
          R:= <R|(newcol:= R[..,maxij[1]] *~ R[..,maxij[2]])>;
          R[..,maxij]:= R[..,maxij] *~  (1 -~ <newcol|newcol>)
     od
end proc:

 Note that I chose to return a new matrix rather than modify the input matrix M.

The above uses Maple 2018 syntax for embedded assignments. If you need to use it in an older Maple, let me know. It'll be easy to retrofit.

Use

op~([[1,2],[-2,1]], simplify(piecewise(op(f(t)), undefined)));
                                           [-1, 1]

We essentially have a pair of recurrences, one for a(n) and one for S(n). If we can eliminate one of two variables, then we can use the makeproc option of rsolve to get a numerical solver for the other. This is easy because a(n) = S(n) - S(n-1). Thus

SP:= rsolve({S(n)-S(n-1) = 2*S(n)^2/(2*S(n)-1), S(1)=1}, {S(n)}, makeproc):
SP(100)-SP(99);
                                         
 -2/39203

Note that no summation command is needed; there's not even one hidden in the procedure SP. I hope that Acer considers this to be the clever solution that he was expecting. 

The recurrence is nonlinear, so I don't have much hope for a closed-form solution.

You can extract the coefficients like this:

Jets:= {u,v}(x,y);
wave:= #You need to apply ToJet to the whole equation.
   ToJet(
      x*y*(diff(u(x,y),y,y) - diff(c(x,y)^2*diff(u(x,y),x),x)) - 
         TotalDiff(F(x, y, u[], u[1], u[2], v[], v[1], v[2]), y) + 
         TotalDiff(P(x, y, u[], u[1], u[2], v[], v[1], v[2]), x) = 
         0, 
      Jets
   );
#These are the 2nd derivatives that you want:
Jxy:= indets(wave, index~(op~(0,Jets), identical(op~(Jets)[])$2));
#The main coefficient-extraction command:
Cfs:= coeffs(collect((lhs-rhs)(wave), Jxy, distributed), Jxy, 'terms'):
#It needs to have its output put into a user-friendly form:
Cfs:= table([terms]=~[Cfs]):
#Now all coefficients are available by indexing Cfs:
Cfs[1]; #"constants" term
Cfs[u[x,x]]; #coeff of u[x,x] term

 

Where to start: Look up command ?addcoords

You are unknowingly mixing up types and properties in that you're expecting a type to act like a property. Here's a discussion of both. Although it may seem like properties are much more powerful, you'll definitely want to stick with types in this case for their robustness, definitiveness, and simplicity of programming.

Given any Maple data structure x and any type t, either x definitely has or definitely doesn't have type t---there are never nebulous cases where possesion of the type can't be determined (due to x being symbolic or any other reason)[*1]. So, if x is not numeric, then it's definitely not of type integer nor type even. Examples of types include numericintegerevenoddalgebraic, and complexcons.

Types can be contrasted with properties, which can be nebulous (i.e., subject to 3-valued logic). The commands to check whether x has property p are is(x::p) and coulditbe(x::p), and one of these four cases applies:

  1. x definitely has the property;
  2. x definitely doesn't have the property;
  3. mathematically, there's not enough given information (in the current assumptions) to determine whether x has the property;
  4. Maple cannot determine whether x has the property although there's theoretically enough information to make that determination.

The corresponding returns from is or coulditbe are truefalseFAILFAIL, respectively, for the four cases. These are the values of Maple's 3-valued logic. (No attempt is made to distinguish cases 3 and 4.) The difference between is and coulditbe is significant when x is symbolic and it corresponds to universal or existential quantification:

  • Universal (is): Do all possible values of x under the current assumptions have the property?
  • Existential (coulditbe): Does there exist some value of x under the current assumptions that has the property?

An example of a property that isn't also a type is real. Unfortunately, there are several names which can be used as both types and properties, easily leading to the confusion that caused you to ask this Question.

Obviously from the above discussion, working with properties is quite subtle, and I haven't even discussed what precisely is meant by the current assumptions. However, it's far more important that you learn to work with types than with properties, so I won't discuss properties any further in this article.

It happens very often that you want a procedure to do nothing when it's given non-numeric input or other input that it can't or shouldn't handle. Formally speaking, you want the procedure to return unevaluated. In these cases, the procedure's return value can be coded as 'procname'(args). Thus, your even/odd procedure could be

M:= (n::And(algebraic, Or(integer, Not(complexcons))))-> 
   `if`(n::integer, n mod 2, 'procname'(args))
:

Notes:

  • In those cases where it'll do the job, `if` is far more efficient and far more robust than piecewise.
  • When a::b appears in a context requiring a true/false value, it's essentially equivalent to type(a, b), but more robust because it works even if a = NULL.
  • My type declaration for n---And(algebraic, Or(integer, Not(complexcons)))---is intended to exclude (with an error condition) manifestly garbage input such as 6.3 or [x, y, z]; i.e., things that could never be integers even if their symbols, if any, were given numeric values.

[*1] It's possible to define types (and this can very easily happen through sloppy programming) that do not return true, false, or error for some inputs. There is never any good reason to do this, and it can lead to very serious problems, including kernel crashes. (Note that error is not the same as FAIL.)

Please respond to my Answers!

Use plots:-display(a, b, c) because display is in the plots package and always has been.

Your older worksheets probably included the command with(plots), which would've allowed future references in the same session to be display(...rather than plots:-display(...); however, I prefer to explicitly use package-name prefixes such as plots:- whenever possible.

If you have a solution set or list named, for example, Sol, and it contains equations such as {A = 3.54, B = 4.67}, then you can do assign(Sol).

To go downhill at locally maximal descent (like water would), follow the negative gradient. Here, I've done it with dsolve, but there may be another way. The path will stop at any local minimum or saddle point, of course, which is what happens in this plot.

restart:
f:= (x,y)-> 3*(1-x)^2*exp(-x^2-(y+1)^2) - (2*x-10*x^3-10*y^5)*exp(-x^2-y^2) - 1/3*exp(-(x+1)^2-y^2):
bp:= <0.2, 1.4>: #initial point.
Sol:= dsolve(
   {diff(X(t),t) = -D[1](f)(X(t),Y(t)), diff(Y(t),t) = -D[2](f)(X(t),Y(t)), X(0)=bp[1], Y(0)=bp[2]},
   numeric
):
plots:-display(
   plot3d(f, -3..3, -3..3),
   plots:-odeplot(Sol, [X(t), Y(t), f(X(t),Y(t))], t= 0..1, color= red, thickness= 3),
   orientation= [-40,60,0]
); 

My choice of t=1 as an endpoint for the integration was just a guess, but it's at or near a local minimum, as can be seen by rotating the plot.

The procedure Diffs that you want can be written like this:

Diffs:= proc(e::algebraic)
local t;
     subsindets(
          subsindets(
               diff(subsindets(e, And(name, Not(constant)), n-> n(t)), t),
               'diff'(anyfunc(identical(t)), identical(t)),
               d-> PutDelta(op([1,0], d))
          ),
          anyfunc(identical(t)),
          f-> op(0,f)
     )
end proc:

where PutDelta is as specified by Acer.

As far as your computer cares, there's no meaningful difference between a .txt and a .mpl file. The only purpose of ".mpl" is long-standing tradition (at least 42 years) that plaintext files of computer code have a file "extension" (the part after the dot) that indicates the language that the file is written in. So, there's no conversion; you simply rename the file. Alternatively, Maple would be just as happy to read the .txt file.

Maple has a built-in conditional ternary operator `if`. Note that the backquotes distinguish it from if as used in if-statements. It has smart evaluation rules: Only 1 of the 2nd and 3rd operands gets evaluated, becoming the operator's return value.

`if`(x=3, 1, 0)*x^2

`if`(g(x)=x^2, 1, 0)*f(x)

If you're defining objects, then it's possible to define the meaning of [...] when it's placed to the right of those objects. So, in that case, you could do it exactly the way you asked. DataFrames are examples of objects where the brackets are defined in a way similar to what you suggest. They are essentially matrices that can be indexed by boolean relations.

My code for this uses irem, which computes both an integer quotient and its remainder in one step. It also uses multiple assignment, which allows one to switch two variables without using an intermediate third variable. And, finally, this code works for any integers a and b, regardless of their signs or which is greater.

GCDwithBezout:= proc(a::integer, b::integer)
local q, r0:= a, r1:= b, s0:= 1, s1:= 0; 
     while r1 <> 0 do
         (r0, r1):= (r1, irem(r0, r1, 'q'));
         (s0, s1):= (s1, s0 - q*s1)
     od;
     sign(r0)*[r0, s0, `if`(b=0, 0, iquo(r0-s0*a, b))]
end proc:

 

Method using strictly the techniques of single-variable calculus:

You need to use function variables, which are expressions such as f(x) that show a dependency between a function and its independent variable(s). You want the derivative with respect to t, which makes t the independent variable. So, you need to replace z with z(t) in your original equation: 

Eq0:= z*t = cos(z + t):  #original equation
Eq1:= subs(z= z(t), Eq0); #function variable adjustment

Now, assuming that you understand the rules of explicit differentiation (most importantly for this problem the product rule), there are only two more steps needed to do implicit differentiation. First, take the derivative with respect to t of both sides of the equation:

Eq2:= diff(Eq1, t); #both sides done with one command!

And then solve for the derivative:

Ans:= solve(Eq2, diff(z(t), t));

If you were solving Eq2 by hand for the derivative, note that the equation is always linear in the derivative and thus easy to solve by Algebra-I methods.

An optional clean-up step would be to re-express the answer with the original z instead of z(t):

subs(z(t)= z, Ans);
 

Much easier method that uses a tiny bit of multi-variable calculus:

Amazingly, all of the above can be combined into two very short steps using a simple idea of multi-variable calculus: If we subtract one side of the original equation from the other, then the resulting expression can itself be considered a function of two independent variables, z and t. There's a remarkable and simple relationship between the derivatives of this new function, F, with respect to its independent variables and the derivative that we want:  dz/dt = - (dF/dt) / (dF/dz). To remember that formula, you can imagine that these are fractions where the dF cancels; then include a minus sign. Now, professors and textbooks may make a distinction between ordinary derivatives and partial derivatives--and they use a fancy curly letter d for the partials--but there's really no practical difference and Maple doesn't care. 

The first short step is to subtract one side from the other:

Eq:= z*t = cos(z+t): #original
F:= (lhs-rhs)(Eq); #left-hand side (lhs) - right-hand side (rhs)

And then apply the derivative relation that I explained:

Ans:= - diff(F,t) / diff(F,z);

That's all that there is to it! If you were doing it by hand, it doesn't even require the product rule or solving an equation for the derivative! Since this method is so much easier and so much less prone to error (when doing by hand), I recommend it to all my single-variable calculus students as a means of checking their work done by the first method, which their formal instructors may require them to use.

Implicit derivatives can usually be expressed in multiple equivalent forms which are totally correct but whose equivalence is not immediately apparent. To show the equivalence, you may need to reduce with respect to the original equation. 

The command is Statistics:-ColumnGraph. If you can't get the appropriate labels on the horizontal axis, let me know. It's fairly easy, but, unfortunately, no example of that appears on the help page.

First 128 129 130 131 132 133 134 Last Page 130 of 395