Try this Google search:

"simple beam" ("maple (code|file|worksheet|document)" | "maple * (mws|code|file|worksheet|document|mw)")

(It sucks that the Google search operator * seems to stand for "one or more intervening words" rather than "zero or more intervening words." I think that's a recent undocumented change.)

When you find a worksheet, if you need help understanding it, don't hestitate to ask.

@Markiyan Hirnyk Thus ScientificErrorAnalysis can't be used as a substitute for Tolerances, which does do range or interval arithmetic (but doesn't handle complex values very well).

@Markiyan Hirnyk No, that is not the point of my remark. My point is that the correct answer is the interval 0..4. If a and b are in 0..2, then a+b could be anywhere in 0..4. The interval 2-sqrt(2)..2+sqrt(2) is not wide enough.

@Markiyan Hirnyk Note that ScientificErrorAnalysis, in particular combine(..., errors), doesn't do range or interval arithmetic. Compare

with(ScientificErrorAnalysis):
a:= Quantity(1,1):  b:= Quantity(1,1):
combine(a+b, errors);

with

a:= shake(1,1):  b:= shake(1,1):
evalr(a+b);

@nm Yes all intervals should be specified with two endpoints. There are other commands in Maple that take complex intervals as a+b*I..c+d*I. There's no good reason that INTERVAL should be any different.

@nm Please reread my Answer because I just expanded it with information about how to handle complex ranges, which are necessary to handle your original example. Note that I changed your b interval for my evalr example to ensure that the solutions were real.

If a=4, b=1, and c=2, then I'm sure that you can solve by hand, or with Maple, and see that the solutions are not real. I don't know the Tolerances package, but my guess is that it is only showing you the intervals for the real parts of the solutions.

But your equation doesn't necessarily have real solutions under the given conditions. Consider a=b=c=1/2.

@tomleslie That's not what I meant by "Don't use map."

@tomleslie By "decimal numbers" I meant numbers with decimal points---but you were right to correct my terminology----yes, they are floating point.

Regarding inert functions and mod:  mod is all about the inert functions (see ?mod): There are 45 predefined inert functions that work with mod (including Det), and it's very easy to write your own.

What kind of answer did you expect? Let's ignore the issue of determinants for the moment. What do you expect as the result of applying modular arithmetic to decimal numbers?

@brian bovril Your problem is in the initial conditions ics. You have dancer 0 at [-2,-2], dancer 1 at [0,0], and dancer 2 at [2,2]. Thus they start out on a straight line, not the vertices of a triangle. And, of course, if they start on a straight line, then they'll stay on a straight line.

If you want an equilateral triangle with edge length 4, then use the following as the initial points:

Init_Pts:= 4/sqrt(3)*~[cos,sin](-2*Pi*k/3) $ k= 1..3;

Under these conditions, the exact length of one spiral is 8/3.

Basic facts from vector calculus: The derivative of each dancer's position vector is their direction vector. A direction vector can be expressed as B-A where A is the dancer's current position and B is any point toward which they are heading. A point toward which a dancer is heading is the position of the next dancer (clockwise).

@Markiyan Hirnyk Dancer 0 moves towards dancer 1, 1 moves towards 2, 2 moves towards 3, and 3 moves towards 0. This can be compactly described as "k moves towards irem(k+1,4) for k= 0..3." The magnitude of the velocity of the motion is irrelevant so long as it is the same for all. We only need to account for the direction of the velocity. Hence, the x component of 0's velocity is described by

diff(x0(t), t) = x1(t) - x0(t).

Likewise for the y component, and likewise for all four dancers. Is that sufficient explanation?

@Mac Dude The file generated by setting kernelopt(profile=true) is not meant to read by a human! You're supposed to let the commands exprofile and excallgraph read it. Follow the example given at ?profile.

@Markiyan Hirnyk The vast majority of the problems that Brian posts are ones that can be fairly easily solved with Maple with some thought but are difficult to solve without symbolic computation. I find them quite interesting, and I think that they are great material for MaplePrimes.

Regarding the Maple code to form the required equations, see my solution below. Especially note how seq and cat are used to form the required equations.