Download Tensor_Products_of_Quantum_States_-_2018.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

It can be considered as continuation of these topics: “Determination of the angles of the manipulator with the help of its mathematical model. Inverse problem.”  and  “The use of manipulators as multi-axis CNC machines”.
There is a simple two-link manipulator with three degrees of freedom. We change its last link with a fixed length to a variable length link. By this action we added one degree of freedom to our manipulator. Now we have a two-link manipulator with 4 degrees of freedom.
In a particular mathematical model the variable length of the link is related to the x7, and in the figure the total length of the last link is displayed as the result of subtracting the fixed part of the link (L2) from x7 (equation f2). At the same time, the value of the variable x7 depends on the inclination of the first link (equation f4).  x1, x2, x3 are the coordinates of the moving point of the first link, x4, x5, x6 are the coordinates of the operating point.  The  equation f2 defines the type of connection between the links, the equations f5 and f6  are the trajectory of the working point.

MAN_2_4_Variable_length_MP.mw

Here is a classic puzzle:
You are camping, and have an 8-liter bucket which is full of fresh water. You need to share this water fairly into exactly two portions (4 + 4 liters). But you only have two empty buckets: a 5-liter and a 3-liter. Divide the 8 liters in half in as short a time as possible.

This is not an easy task and requires at least 7 transfusions to solve it. 

The procedure  Pouring  solves a similar problem for the general case. Given n buckets of known volume and the amount of water in each bucket is known. Buckets can be partially filled, be full or be empty (of course the case when all is empty or all is full is excluded). With each individual transfusion, the bucket from which it is poured must be completely free, or the bucket into which it is poured must be completely filled. It is forbidden to pour water anywhere other than the indicated buckets.

Formal parameters of the procedure: BucketVolumes  is a list of bucket volumes,  WaterVolumes  is a list of water volumes in these buckets. The procedure returns all possible states that can occur during transfusions in the form of a tree (the initial state  WaterVolumes  is its root).

restart;
Pouring:=proc(BucketVolumes::list(And(positive,{integer,float,fraction})),WaterVolumes::list(And(nonnegative,{integer,float,fraction})), Output:=graph)
local S, W, n, N, OneStep, j, v, H, G;
uses ListTools, GraphTheory;

n:=nops(BucketVolumes); 
if nops(WaterVolumes)<>n then error "The lists should be the same length" fi;
if n<2 then error "Must have at least 2 buckets" fi;
if not `or`(op(WaterVolumes>~0)) then error "There must be at least one non-empty bucket" fi;
if BucketVolumes=WaterVolumes then error "At least one bucket should not be full" fi;
if not `and`(seq(WaterVolumes[i]<=BucketVolumes[i], i=1..n)) then error "The amount of water in each bucket cannot exceed its volume" fi;
W:=[[WaterVolumes]];

OneStep:=proc(W)
local w, k, i, v, V, k1, v0;
global L;
L:=convert(Flatten(W,1), set);
k1:=0; 
for w in W do
k:=0; v:='v';
for i from 1 to n do
for j from 1 to n do
if i<>j and w[-1][i]<>0 and w[-1][j]<BucketVolumes[j] then k:=k+1; v[k]:=subsop(i=`if`(w[-1][i]<=BucketVolumes[j]-w[-1][j],0,w[-1][i]-(BucketVolumes[j]-w[-1][j])),j=`if`(w[-1][i]<=BucketVolumes[j]-w[-1][j],w[-1][j]+w[-1][i],BucketVolumes[j]),w[-1]); fi;
od; 
od; 
v:=convert(v,list);
if `and`(seq(v0 in L, v0=v)) then k1:=k1+1; V[k1]:=w else 
for v0 in v do  
if not (v0 in L) then k1:=k1+1; V[k1]:=[op(w),v0] fi;
od;
fi;
L:=L union convert(v,set);
od;
convert(V,list);
end proc:

S[0]:={};
for N from 1 do
H[N]:=(OneStep@@N)(W);
S[N]:=L;
if S[N-1]=S[N] then break fi;
od;
if Output=set then return L else
if Output=trails then interface(rtablesize=infinity);
return <H[N-1]> else
G:=Graph(seq(Trail(map(t->t[2..-2],convert~(h,string))),h=H[N-1]));
DrawGraph(G, style=tree, root=convert(WaterVolumes,string)[2..-2], stylesheet = [vertexcolor = "Yellow", vertexfont=[TIMES,20]], size=[800,500])  fi; fi;

end proc: 

Examples of use:

Here is the solution to the original puzzle above. We see that at least 7 transfusions are  
required to get equal volumes (4 + 4) in two buckets

Pouring([8,5,3], [8,0,0]);
           

 With an increase in the number of buckets, the number of solutions is extremely 
 increased. Here is the solution to the problem: is it possible to equalize the amount of water (7+7+7+7) in the following example? 

Pouring([14,10,9,9],[14,10,4,0]);
S:=Pouring([14,10,9,9],[14,10,4,0], set);
is([7,7,7,7] in S);
nops(S);
         

Download Pouring.mw

Am pondering how to best provide user-configurable options for a few packages I've written. The easiest method is to use global variables, preassign their default values during the package definition (but don't protect them) and save them with the mla used for the package. A user could then assign new values, say in their Maple initialization file or in a worksheet.  For example

  FooDefaultBar := true:
  FooDefaultBaz := false:

That works for a few variables, but is unwieldy if there are many, as the names generally have to be long and verbose to avoid accidental collision. Better may be to use a single record

  FooDefaults := Record('Bar' = true, 'Baz' = false):

To change one or more values, the user could do

   use FooDefaults in
      Bar := false;
   end use:

A drawback of using a global variable or record is that the user can assign any type to the variable, so the using program will have to check it. While one could use a record with typed fields, for example,

  FooDefaults := Record('Bar' :: truefalse = true, 'Baz' :: truefalse := false):

that only has an effect on assignments if kernelopts(assertlevel) is 2, which isn't the default.

A different approach is to use a Maple object to handle configuration variables. The object should be defined separate from the package it is configuring, so that the target package doesn't have to be loaded to customize its configuration. I've created a small object for this, but am not satisfied with its usage. Here is how it is currently used

# Create configuration object for package foo
Configure('fooDefaults', 'Bar' :: truefalse = true, 'Baz' :: truefalse = false):

The Assign method is used to reassign one or more fields

Assign(fooDefaults, 'Bar' = false, 'Baz' = true):

If a value does not match the declared type, an error is raised. Values from the object are available via the index operator:

   fooDefaults['Bar'];

Am not wild about this approach, the assignment seems clunky and would require a user to consult a help page to learn about the existence of the Assign method, though that would probably be necessary, regardless, to learn about the defaults themselves. Any thoughts on improvements? Attached is the current code.

Configure := module()

option object;

local Default # record of values
    , Type    # record of types
    , nomen   # string corresponding to name of assigned object
    , all :: static := {}
    ;

export
    ModuleApply :: static := proc()
        Object(Configure, _passed);
    end proc;

export
    ModuleCopy :: static := proc(self :: Configure
                                 , proto :: Configure
                                 , nm :: name
                                 , defaults :: seq(name :: type = anything)
                                 , $
                                )
    local eq;
        self:-Default := Record(defaults);
        self:-Type    := Record(seq(op([1,1], eq) = op([1,2], eq), eq = [defaults]));
        self:-nomen   := convert(nm,'`local`');
        nm := self;
        protect(nm);
        self:-all := {op(self:-all), self:-nomen};
        nm;
    end proc;

export
    ModulePrint :: static := proc(self :: Configure)
    local default;
        if self:-Default :: 'record' then
            self:-nomen(seq(default = self:-Default[default]
                            , default = exports(self:-Default)
                           ));
        else
            self:-nomen();
        end if;
    end proc;

export
    Assign :: static := proc(self :: Configure
                             , eqs :: seq(name = anything)
                             , $
                            )
    local eq, nm, val;
        # Check eqs
        for eq in [eqs] do
            (nm, val) := op(eq);
            if not assigned(self:-Default[nm]) then
                error "%1 is not a default of %2", nm, self:-nomen;
            elif not val :: self:-Type[nm] then
                error ("%1 must be of type %2, received %3"
                       , nm, self:-Type[nm], val);
            end if;
        end do;
        # Assign defaults
        for eq in [eqs] do
            (nm, val) := op(eq);
            self:-Default[nm] := val;
        end do;
        self;
    end proc;

export
    `?[]` :: static := proc(self :: Configure
                            , indx :: list
                            , val :: list
                           )
    local opt;
        opt := op(indx);
        if not assigned(self:-Default[opt]) then
            error "'%0' is not an assigned field of this Configure object", indx[];
        elif nargs = 2 then
            self:-Default[opt];
        elif not val :: [self:-Type[opt]] then
            error "value for %1 must be of type %2", opt, self:-Type[opt];
        else
            self:-Default[opt] := op(val);
        end if;
    end proc;

export
    ListAll :: static := proc(self :: Configure)
        self:-all;
    end proc;

end module:

Later: Observing that this is just a glorified record with an assurance that the values match their declared types, but with less nice methods to set and get the values, I concluded that what I really want is a record that enforces types regardless the setting of . Maybe created with

   FooDefaults := Record[strict]('Bar' :: truefalse = true, 'Baz :: truefalse = false):

In the meantime, I'll probably just use a record and not worry about whether a user has assigned an invalid value.

Hoping to get your very own copy of Maple for Christmas? 

No, I'm not about to announce a sale. No crass commercialism allowed on MaplePrimes!  But we have created this handy-dandy letter for Santa that students can use to try to convince him to put Maple under the tree this year*.

Happy holidays from Maplesoft!

*Results not guaranteed, but we hope you will agree we made a valiant attempt. :-)

On the convex part of the surface we place a curve (not necessarily flat, as in this case). We divide this curve into segments of equal length (in the text Ls [i]) and divide the path that our surface will roll (in the text L [i]) into segments of the same length as segments of curve. Take the next segment of the trajectory L [i] and the corresponding segment on the curve Ls [i], calculate the angles between them. After that, we perform well-known transformations that place the curve in the space so that the segment Ls [i] coincides with the segment L [i]. At the same time, we perform exactly the same transformations with the equation of surface.

For example, the ellipsoid rolls on the oX1 axis, and each position of the ellipsoid in space corresponds to the equation in the figure.
Rolling_of_surface.mw

And similar examples:

Download PDE_and_BC_during_2018.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Error when running 'm_model.m' to generate simulink function block when using 'Group all parameters into nested structure'. No errors when using 'Do not group parameters'.

Error using m_fullSwing (line 125)
Invalid setting in 'MapleSim_fullSwing/MapleSim_fullSwing/MapleSimParameters' for parameter 'Value'.
Caused by:
    Error using m_fullSwing (line 125)
    Expression '[Param.Address.ArmPlane, Param.Address.ClubRelHand,  ... ]' for
    parameter 'Value' in 'MapleSim_fullSwing/MapleSim_fullSwing/MapleSimParameters' cannot be evaluated.
        Error using m_fullSwing (line 125)
        Error: Invalid expression. When calling a function or indexing a variable, use parentheses. Otherwise, check for
        mismatched delimiters.
 

Yesterday, I accidentally discovered a nasty bug in a fairly simple example:

restart;
Expr:=a*sin(x)+b*cos(x);
maximize(Expr, x=0..2*Pi);
minimize(Expr, x=0..2*Pi);
                                    

I am sure the correct answers are  sqrt(a^2+b^2)  and  -sqrt(a^2+b^2)  for any real values  a  and  b .  It is easy to prove in many ways. The simplest method does not require any calculations and can be done in the mind. We will consider  Expr  as the scalar product (or the dot product) of two vectors  <a, b>  and  <sin(x), cos(x)>, one of which is a unit vector. Then it is obvious that the maximum of this scalar product is reached if the vectors are codirectional and equals to the length of the first vector, that is, sqrt(a^2+b^2).

Bugs in these commands were noted by users and earlier (see search by keywords bug, maximize, minimize) but unfortunately are still not fixed. 

The attached worksheet develops a procedure for extrapolating boundary data from a square to its interior.  Specifically, let's consider the square [−1,1]×[−1,1] and the continuous functions u₁, u₂, u₃, u₄ defined on its edges. The procedure constructs a continuous function u(x,y) in the interior of the square which matches the boundary data.

The function u(x,y) is necessarily discontinuous at a corner if the boundary data of the edges meeting at that corner are inconsistent.  However, if the boundary data are consistent at all corners, then u(x,y) is continuous everywhere including the boundary.

Here is what the extrapolating function looks like:

Download putnam2018.mw

Edit.
Maple can be also very useful in solving the difficult problem B6; it can be reduced to compute the (huge) coefficient of x^1842 in the polynomial

g := (1 + x + x^2 + x^3 + x^4 + x^5 + x^9)^2018;

The computation is very fast:

coeff(g, x, 1842):   evalf(%);
         0.8048091229e1147

While generating a 3D plot of the solution of an ODE with a parameter, I noticed that better performance could be obtained by calling the plot3d command with a procedure argument, done in a special manner.

I don't recall this being discussed before, so I'll share it. (It it has been discussed, and this is widely known, then I apologize.)

I tweaked the initial conditions of the original ODE system, to obtain a non-trivial solution. I don't think that the particular nature of the solution has a bearing on this note.