It works in Maple 2017 onwards.

If you copy&paste that pretty-printed output then what you get pasted in contains,

    1/(4*(x - 2))

And that becomes 1/(4*x - 8) due to automatic simplification.

However, if instead you line-print rf using the lprint command then you can get a (more correct and accurate) input form, which here happens to not automatically simplify.

Download lprint_pasted.mw

ps. As a long-standing habit I almost never copy&paste from 2D Output, due to various historical issues and problems with doing so. I usually copy from line-printed form.

Those are available in my Maple 2021.1 from the Large Operators palette.

Here's a way that doesn't require the ad hoc steps either of having to enter 3/100 manually or of having to refer to subexpression position via subsop. (It's so ad hoc that one might as well manually and explicitly write out the desired result, with protection against automatic simplification.)

Retaining the number of trailing zeroes (or not) is possible, but more effort.

Download some_float_thing.mw

Also, we don't know whether you want a result that can be further manipulated (I guess so), or just a nice printing of the desired form. That can affect how some approaches are set up. Please provide the context.

An alternative is to freeze (or equivalent) the floats, after pulling off their sign. Then factor, revert while protecting against automatic simplification, etc. The trick there is ensuring that any minus-sign doesn't accidentally also get factored out front...

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.