Carl Love

Carl Love

23928 Reputation

25 Badges

9 years, 309 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

Do you mean that you want to take an equation such as 

F = x^(1/2)*ln(x)

and solve it for x? It can be done for some simple cases, such as the one shown. The command is solve:

solve({F = x^(1/2)*ln(x)}, {x}); 

I think that what you're referring to as "extracting a variable to one side of the formula" is what we usually refer to as "solving an equation for a variable".

Some even shorter code:

AreRowsUnique:= (A::Matrix)-> #Are the rows of A unique?
    evalb(nops({convert(A, 'listlist')[]}) = op([1,1], A))
:
IsRowPerm:= (A::Matrix, B::Matrix)-> #Is A a row permutation of B?
   #evalb(`=`(({op}@convert)~([A,B], 'listlist')[]))
    evalb(`=`((sort@convert)~([A,B], 'listlist')[])) #VV's correction
:

 

I see that convert(..., listlist) is labelled as "deprecated" but that it gets translated directly to convert(..., list, nested). I'd be happy to respect the "deprecated" if someone could tell me What's the point of labelling something as deprecated just to change its name, especially if it's a longer name?

If I expand the integrand and use the multiple-integral syntax where the limits are given as a list, then I get a simple (i.e., with no piecewise) analytic result that agrees with the numeric one:

restart:
R:= 1:  delta:= 1:
f:= 
    R^4*delta*cos(theta)*sin(x)*sin(-x+theta) /
    (8*Pi*(R^2*cos(x)+sqrt(2*R^2*cos(x)+2*R^2+4*delta^2)*delta+R^2+2*delta^2))
:
Int_f:= Int(expand(f), [x= -Pi+theta..Pi+theta, theta= 0..2*Pi]);
<intAna, intNum> =~ <((eval = evalf)@value, evalf)(Int_f)>; 

 

The reasons that this works are:

  • Using expand, the integrand can be expressed as a sum of terms each of the form f1(theta)*f2(x). In other words, the variables can be separated.
  • Using the combined multiple-integral syntax, it can tell that the range of theta is such that the piecewise isn't needed.

Sometimes you want to have a package initialization that is specific to using with; in those cases, give the package an exported nullary (i.e., 0 arguments) procedure named init. This is independent of whether the package also has a ModuleLoad.

restart:
Package:= module()
option package;
local ModuleLoad:= ()-> print("In ModuleLoad");
export init:= ()-> print("In init");
ModuleLoad() #In case module didn't come from an archive
end module
:
                        "In ModuleLoad"

with(Package):
                           "In init"

 

To use frontend practically with solve in these cases, you need to let solve look inside the subexpressions that contain A; but to preserve the original form (as much as is possible) you don't want it to look inside the subexpressions that don't contain A. The way to do that is:

frontend(solve, [A = (1/2+x+y)^3], [{}, {identical(A)}], A);

A more realistic example:

frontend(solve, [A = A^2 + (1/2+x+y)^3], [{}, {identical(A)}], A);

You wrote:

  • Why does this happen? It is the same equation.

But implicitplot is just working numerically, not symbolically. It does not see your input as an equation y - x/(2-x) = 0 but rather as a numeric "black-box" procedure: w:= (x::numeric, y::numeric)-> y - x/(2-x). Using this, all it can do is pass in numeric values of x and y, obtain those numeric results, and use those to make a guess about how many "pieces" (connected curves) the plot has.

Yes, the transformation can be done more easily and more universally like this:

`convert/atan2`:= rcurry(evalindets, ' 'arctan' '(algebraic), arctan@op@[numer,denom]@op):

You can store that in your personal library, module, or initialization file.

Example usage:
eq:= phi = arctan(A/B) - arctan(B/A):
convert(eq, atan2);

             

It makes no difference how complicated the target expression is or how many arctans it has. It'll even work on nested arctans. 

It's very likely that your integrals can be speeded up by adding the option numeric to their integration commands, for example,

int(sin(x), x= 0..Pi, numeric)

But Maple Flow is a listed choice. As you can now see in your Question's header, I edited it so that Maple Flow and MaplePrimes have been checked.

Sorry, I misunderstood your Question (due to my relative lack of familiarity with the "tabs" in MaplePrimes compared to the controls and check boxes that I often use for editing Questions and Posts). You are correct that it's missing and should be listed.

Like this:

y:= <1,2,3,4,5,6>:
x1:= <10,20,30,40,50,60>:
x2:= <0.1,0.2,0.3,0.4,0.5,0.6>:
#Note that I entered the above with angle brackets to make them vectors rather than lists.

plots:-dualaxisplot(
    plot(<y|x1>, labels= ['y', 'x1']),
    plot(<y|x2>, labels= ['y', 'x2'])
);

There are two lines plotted. It only looks like one line because, of course, in this case one line is on top of the other. You can also plot points instead of lines, or any combination of the two.

anti:= int(1/(a+x^(1/5)), x);
simplify(allvalues(combine(%)));

See the help page ?Explore. The Explore command displays its results (which could be plots, animations, regular output, or any combination thereof) in a different interface than Maple's usual. It allows for any number of parameters with on-screen controls.  

You wrote:

  • So I am guessing what happens is this: doing DEtools:-name_of_solver Maple first searched for a proc called name_of_solver inside DEtools package, and found none. So it does not work.

Correct.

  • But adding eval first, then name_of_solver is evaluated and replaced by abelsol and after that the call is made, and it then finds this proc inside the DEtools package.

Correct, although I'm surprised that that use of eval is allowed.

  • But my question is, why is eval needed here? Is it not automatically happens that a variable is replaced by its value?

Evaluation/replacement does not happen to the operand on the right side of the :- operator, with good reason, explained below. If you want the evaluation to happen, you should use DEtools[name_of_solver].

  • Why the rule of evaluation is different in this case?

A module's exports are a form of local variable. If the :- operator didn't work the way that it does, then how would someone writing a module know that the names that they used for the exports weren't being used as globals?

Here's my procedure for the lexicographic product of graphs. I made it work for any number of factors.

LexProd:= proc(G::seq(Graph), $)
uses GT= GraphTheory;
local
    LexProd2:= proc(G::Graph, H::Graph)
    local 
        (Vg,Vh):= op(GT:-Vertices~([G,H])),
        (ng,nh):= op(`..`~(1, nops~([Vg,Vh]))),
        (Ng,Nh):= op(op~(4, [G,H])),
        i, j, J,
        P:= [seq](seq([i,j], j= nh), i= ng),
        k:= 0, K:= table((p-> op(p)= ++k)~(P))
    ;
        GT:-Graph(
            (curry(nprintf, "%a:%a")@((i,j)-> (Vg[i],Vh[j]))@op)~(P),                
            (
                ((i,j)-> {
                    seq(seq(K[k,J], k= Ng[i]), J= nh), 
                    seq(K[i,k], k= Nh[j])
                })
                @op
            )~(P)            
        )
    end proc
;
    if nargs=0 then error "at least 1 graph needed"
    elif nargs=1 then G[1] 
    else foldl(LexProd2, args) 
    fi
end proc
: 

 

If you cube both sides of the equation to remove fractional exponents, then you'll get 3 solutions, 2 of which are trivial, and the 3rd is much simpler than your solution above. Using odetest~ quickly returns 0 for all 3.

restart;
ode:= diff(y(x),x)^3 = x^3*(y(x)^2-1)^2;
sol:= [dsolve](ode);
odetest~(sol);

 

1 2 3 4 5 6 7 Last Page 3 of 352