If this is supposed to represent an actual mechanical process, then it difficult to understand what is controlling the complicated rotations of the cam; whereas with your 2d cam (previous post), it is easy to understand.

@Markiyan Hirnyk 

I don't know the internal workings of DirectSearch:-Search, but the points that you are being shown are all the points at which the objective function is being evaluated. The only reason that I displayed them was so that you could see that some progress was being made. If you stop seeing a new point every few minutes, then it might be a good guess that it is stuck in some infinite loop.

Uh oh.... I just noticed another potential problem. I suppose that you expect that the a, b, x_1, phi_1, etc. that you use as global variables in the setup code will be the same as the a, b, x_1, phi_1, etc. that you use as the parameters to dist. It doesn't work that way; the variables are not the same even though they have the same names. Anything in the setup code that gets used inside a subsequent procedure and which refers that procedure's parameters needs to itself be a procedure---preferably one created with unapply. I don't have the patience to implement this right now. Maybe tomorrow.

@Markiyan Hirnyk 

Your own timing of dist on a test point shows that trying a single point takes more than three minutes.

If you include a userinfo statement in dist (so that you will be informed of each point that is tried), and if you stop using that ridiculous 2d input (which prevents you from seeing the userinfo output until the whole execution group is finished), then you will see that it is actually computing numeric points; whereas if you do the same with your original constraint, then you will see that it is not computing any points at all. At over three minutes per point, this is going to take some time.

Here is an updated worksheet where I have implemented the new constraint, the userinfo, and converted the DirectSearch:-Search call to 1d input.

twocubes_corrected.mw

There are other efficiencies that could be implemented here and there. Most important I think would be making sure that dist is the last constraint checked. It is ridiculous that dist is being called on points for which a > 1. You could replace the objective function in dist with (t1-s1)^2 + (t2-s2)^2 + (t3-s3)^2 and avoid the square root.

@acer 

Preben has found a way with no call to solve or fsolve required. Apparently, boundary conditions can involve more than one derivative, which I wasn't aware of before. In this case, the additional boundary condition is

Note that in the case of a BVP you cannot simply introduce a new function equal to the second derivative because that would make the system a DAE and dsolve has no DAE-BVP solver.

How can we possibly diagnose your problem without seeing any code? Either cut-and-paste your code as plaintext directly into your post, or use the green uparrow on the toolbar (last thing in the second row) to upload a worksheet. Using pictures to post code is frowned upon here because then we need to retype your code.

@acer 

Thanks for confirming my suspicion about the unevaluated D.

I did not mention your other method (augmenting the ODE system before the call to dsolve) in this thread because I don't see how to make it work for a BVP. I understand how to do it for an IVP. If you can make it work for a BVP, please show me.

@nm 

hastype(eval(g,1), specfunc(anything,int));

@Christopher2222 

Great application. Assuming that each window requires four pieces (one side, all the way around) and that the door requires six pieces (both sides, no bottom), the solution is

BinPacking1D(7*12, [[42, 4], [20, 6], [72, 4], [32, 2], [16, 2], [30, 4]]);

for a total of 11 7-ft pieces to buy. Note that this does not take mitered corners into account.

@taro 

As Roman said, products are NOT sorted. Your example expression 2*y*(x*y+2)*(3*y^3+x^2+3*x*y) is a product; it is not stored as a polynomial. It is not sorted. The order of the factors is pretty much random except that numeric factors come first. The factors (x*y+2) and (3*y^3+x^2+3*x*y) are polynomials. Thus, their terms are sorted.

@Bishop556 

You have a division by zero because of y=0.

You should change .5 to 1/2 and 1.5 to 3/2. It will make errors easier to find. In Maple, try to avoid the use of decimal points except for empirically derived constants. Occasionally that is impossible, but keep it as a goal.

Since your procedure psi uses globals x and y and parameters a and b, expressions such as psi(x,y), diff(psi(x,y), x, x), etc. are highly suspicious to me. Do you really intend for x and y to be both the arguments substituted for the parameters and the globals? Shouldn't those expressions be psi(a,b), diff(psi(a,b), a, a), etc.? I don't know enough about the physics to decide that.

@acer The value command changes Int to int even if the resulting int returns unevaluated.

@tomleslie 

Note that the Question is about Maple TA, not regular Maple.

@Mac Dude 

phi does not need to be a Vector, and thus there is no need to construct it first. It can be a table or simply an indexed procedure.

You should post your code.

@lt 

What error message did you get when you ran the code in Maple 13?