Your worksheet seems to have been last saved by you in Maple 13.

Using Maple 16.02 (the oldest I have at hand) it succeeds for your tau_l=0.8 if Digits is raised for the computations done prior to the problematic fsolve call, and if Digits is temporarily reduced for that call.

Download ACCOLLEY_Delali_-_Demographics_3_ac.mw

Download mover_ex.mw

In the last example above the result is an actual expression (which you could further manipulate programmatically if you wanted). It is an unevaluated function call to the unassigned global name queryequal.

In 2D Math entry mode you could get a similar rendering effect directly on input, by using the Layout palette for placing ? above =, etc. Here's what I got with that approach. I put in an extra space on either side of the symbol, and the result was this multiplication of terms. (I don't find that useful for further manipulation. But you could also just use the palette approach for non-executable 2D Math used for discourse rather than further computation.)

Download mover_2dinput.mw

Your original expression assigned to r is or type `+`.

Hence when you map something over that the result will also be a call to `+`. The new summands will be whatever is returned by f, when passed the operands of r. That's some fundamental behaviour of map.

When your procedure f has a call to print as its last statement then it will return NULL, because print returns NULL. That's the difference. In your second example (using print) the result from your map call is NULL, as the addition of the various NULL return values from f.

When you have your procedure f return lists then they too will be added under `+`, when f gets mapped over r. But the manner in which you repeatedly concatenate global list L makes the lists be of different lengths, so adding them is not sensible.

Perhaps you would rather have the procedure f return the operand Z itself, or perhaps NULL explicitly forced, or perhaps Z^2 the result of the action.

different.mw

I leave it to you to decide what reasonable thing you want procedure f to return. (That changing list L is not such a choice...)

The 5rd bullet point in the Description of the Help page for map states,

   "The result of a call to map (unless the fold or reduce option
    described below is used) is a copy of expr with the ith
    operand of expr replaced by the result of applying fcn to the
    ith operand. This is done for all the operands of expr. For
    expressions of type atomic, map(fcn, expr) is identical to
    fcn(expr). For a table or rtable (Array, Matrix, or Vector), fcn
    is applied to each element instead of each operand."

So if you map f over a sum then the result is the sum of f applied to the operands (summands). If you map f over a product then the result is a product of f applied to the operands (multiplicands). And if you map f over another function call then the result is that same kind of call, now made over f applied to its original operands (arguments). Ie,

map(F, a*b*c/d);

  F(a)*F(b)*F(c)*F(1/d)

map(F, a+b+c);

      F(a)+F(b)+F(c)

map(F, g(a,b,c));

    g(F(a),F(b),F(c))

By the way, I don't see why you want to build list L in such a recursive (augmenting) manner. More efficient could be something like, say,

I prefer the first approach below (as Tom suggested) since it's a very easy way to avoid the inefficiency of recomputing h(a) multiple times.

Download ds_rf.mw

Yes, a 3D space-curve can be colored.

(I dug this out of an old directory in which I had worksheets that colored space-curves of knots, eg. by torsion and curvature. The procedure SC constructs a space-curve substructure as well as its corresponding color substructure. Apart from adjusting the cfunc for your example I had to make no other changes. That's because coloring a space-curve is a pretty basic goal. I have previously submitted a request for it in the plots:-spacecurve command.)

I prefer this over using tubeplot -- at least for my purposes -- for aesthetic, performance, and memory considerations.

Download spacecurve_shaded.mw

I used an hfarray for some backwards compatibility, but in more recent Maple I could have used a Array with datatype=float[8].

I didn't use the px(t) and pv(t) and their piecewises, only because they weren't strictly necessary. I'm sure that you could see how they might be incorporated instead.

note: If you don't need to alter Digits while calling these, you can squeeze out faster performance by adding these lines after extracting X and V from sol.
   X:=subsop(3=[remember,system][],eval(X)):
   V:=subsop(3=[remember,system][],eval(V)):
This memoization improves performance in such code as this which invokes X and V more than once at the same t values.

edit: I'll mention that I deliberately made cfunc less efficient than necessary. It could instead have the RGB values (range 0..1) hard coded in the piecewise. Instead it needlessly calls Color and rips those values out, each time it is called. I just wanted to illustrate using the colors by name. So it could be faster, though for this example I expect the DE computation to dominate the cost of color generation. Let me know if you'd like me to show such an edit. The particular RGB values -- or the piecewise -- could even be substituted programmatically into the cfunc proc (once, up front). You could also call that cfunc yourself, and see what it returns directly.

A different and efficient approach for SC would be to have it call `spacecurve` or odeplot itself, rip out the numeric data from its resulting CURVES substructure, and then compute the COLOR substructure using that numeric data directly. That is how Library improved revisions to those routines would ideally be extended to implement the usual coloring options.

The angle-bracket shortcut syntax for Matrix construction supports this functionality. For example,

Download Matrix_stack_augment.mw

That syntax is so simple that having dedicated commands for it would be overkill.

You may also use this to stack/augment a Matrix by a Vector (of the appropriate orientation).

You can suppress the visual display of results by using a fill colon (instead of semicolon) as the statement terminator.

For sorting there are various kinds of example. You should explain the specific goals, explicitly.

You can pass the extra option  output=string  to the CodeGeneration:-Matlab command.

Eg,
   CodeGeneration:-Matlab(func, output=string);

Then you can write that string to a file, using fprintf, or FileTools:-Text:-WriteString, etc.

It sounds like you are looking for a 2D parametric plot.

For example (using made up values for the other parameters),

plot([eval([x(t),y(t)],[A=0.9,v=2,m=1,n=1,alpha=1,beta=1])[], t=0.3..1.5],
        labels=["x","y"]);

With the code you supplied, the following both work:

  ribbonplot5([cos, sin, cos + sin], -Pi .. Pi,numpoints=20);
  ribbonplot5([cos(x), sin(x), cos(x) + sin(x)],x=-Pi .. Pi,numpoints=20);

Consider this simpler plotting example, and these two different kinds of calling sequence,

  plot(sin, 0..Pi);
  plot(sin(x), x=0..Pi);

The first uses a so-called operator-form calling calling sequence syntax, and the second uses a so-called expression-form calling sequence. (Also see the calling sequences shown on this Help page.)

The first passes an operator (procedure), which the second passes an expression with an unknown (here, the name x).

It does not make good sense to mix and match those two distinct kinds of usage. It does not make good sense to pass an operator (procedure) as the first argument and a name in the second argument. That would be muddled up and poor programming.

That ribbonplot5 procedure simply doesn't do as good a job as plot at checking for such a mismatch and producing a helpful error message. Eg,

  plot([sin, cos], x=0..Pi);
Error, (in plot) expected a range but received x = 0 .. Pi

note: This kind of distinction between expression-form and operator-form calling sequence is present elsewhere, eg. for fsolve, evalf(Int(...)), Optimization:-Minimize, etc.

You might use the orientation 3D plotting option.

For example,

Download tareaclase6_ac.mw

An imported image (as float[8] Array) can be used for the coloring in a density-plot structure.

Once appropriately scaled, this can be translated to arbitrary x-y positions.

The following code could be made more efficient (and easy, with a re-usable procedure to scale/translate/etc). But I'd like to know whether it will suffice, before making the effort.

Naturally one can change the Read line below, to instead use some other external image file. (The OP didn't provide an image file.) All the code below needs is the usefully scaled (70x70x3 works ok) Array assigned to img.

Download image_plot.mw

I suspect that the GUI will be generally less sluggish using such density-plots than it would with, say, colored point-plot assemblies.

That density-plot structure could actually be formed via the plots:-densityplot command, using the Array from the image. I simply found it easier to form it directly, as above.

The Fractals:-EscapeTime commands produce images (in the float[8] rtable sense), not plots.

You can "animate" a discrete number of images (or even calls to the Mandelbrot command at modest size, it's that fast) using Explore.

But you cannot nicely export that animated rendering to an external file. Maple's directly export functionality is limited to exporting a sequence of actual plots. Converting those images (rtables) into, say, densityplots would produce results too large and unwieldy for the GUI and its export drivers to handle well (if at all).

What you could do, instead, is export the images (rtables) directly to separate external image files (.gif, .png, what have you), using the ImageTools:-Write command. And then use an external 3rd party tool on your OS to assemble a movie format file (mpeg2, mp4, .gif, etc) from those.

Here are two alternatives to plots:-display, one using DocumentTools:-Tabulate and the other using DocumentTools primitives.

If you really want you could use more Table nesting (and suppressed borders) to get precisely the layout you showed. Perhaps more effort than it's worth...

(Sorry, I don't think that this forum will properly inline this worksheet here.)

question5_ac.mw

I don't why you wouldn't expect a(i)=0 and c(i)=0 to follow from your given a(0)=0 and c(0)=0. Perhaps you (or I) have made a mistake?

For fun, procedures Ap and Cp below take a0,c0 initial values as 2nd and 3rd arguments respectively.

The procedures Ap and Cp are programmatically generated from the recurrence equations. (I didn't feel like wrestling with rsolve.) So you can regenerate them for some modest edits of the equations.

In the example I use a0=0.1 and c0=0.1.

Download rsolve_for_system_of_recursive_equations_acc.mw

There are various ways to programmatically make the result appear in terms of J/mol as units. See attachment below for three of them.

It numerically better to round final results to 3 digits instead of calling evalf(...,3) or evalf[3](...) which do computations at lower precision and can incur unnecessarily greater roundoff error than usual.

I am deliberately avoiding using right-click units-formatting or numeric (float) formatting via the GUI.

(For some reason this forum is not letting me inline my revised Document, sorry).
Download question4_ac.mw

In terms of programmatically determining significant digits you might try either the Tolerances or the ScientificErrorAnalysis packages, depending on your concept of error in the supplied input float values.