For your first query: The exact roots of some cubics may not all be representable in terms of radicals without the imaginary unit being present. That's a math thing, not merely a Maple thing.

For such a representation, floating-point approximation of such roots often results in small imaginary artefacts (eg, 7.6e-10, etc) due to quite usual roundoff error in the float computation.

Representation of such exact real roots in a trig form can avoid the presence of the imaginary unit. Floating-point approximation of those can avoid the small imaginary float artefacts.

Download cubic_sol.mw

For your second query, for systems (more than one variable) fsolve returns just a single root. Here you can utilize fsolve's avoid option to get additional approximate roots.

There is no Maple language command that would export either a Maple .mw worksheet file or its full XML representation to SVG format.

By the way, your code doesn't actually assign to tb, since you used = the syntax for an equation rather than := a syntax for assignment. But it would not matter, regardless. The return value from Tabulate can only be a brief lookup rtable (of the names of GUI components or Tables), or an XML-like representation of a whole worksheet containing the Table. I know of no programmatic way to export that to SVG.

There is already a command for doing this kind of thing with strings. So all that's needed is simple conversion.

Download num_dig.mw

note. I you want to compute the number of occurences of all the possible digits then it might be more efficient to use a single call to StringTools:-CharacterFrequencies instead of multiple calls to CountCharacterOccurrences.

[edit: I've replaced my Answer. I mistakenly thought that I'd tried this approach unsuccessfully.]

You can utilize the UseUnit command to inform Maple how you want units of particular dimension (here, electric_potential^2) to be simplified/combined.

Download units_elec_pot_sq2.mw

Derived units (eg. N, W, V) are named units formed as a compound multiplication/division of so-called base units. Simplification to powers of non-base units doesn't necessarily happen by default. You can specify such using the UseUnit command.

Here's one way.

Download trig_simp_ex.mw

Notes:
 - You used lowercase `i` which means nothing special to Maple by default. In Maple the imaginary unit is capital I by default.
 - You mentioned capitalized Cos in the target expression, but in Maple the trig command is lowercase cos.
 - You mentioned Phi in the target expression, but in the original you used varphi.

You mentioned trying unsuccessfully with.
    combine(b,exp) and simplify(b,trig)
But in fact what is adequate (in the right order) are the other way around, ie.,
    combine(...,trig) and simplify(...,exp)
In other words, the following version is also sufficient,

   simplify(combine(b, trig), exp)

There is no command that can directly cause the GUI to alter the column widths of a GUI Table (whether originally embedded by mouse or by command).

During the same execution run -- while control is still in the same Execution Group -- you can issue a second (or more) Tabulate calls and it will replace the earlier instance. (This can sometimes be useful in loops that take a long time, say.) I suspect that is not your situation.

I suspect that you want to finish execution. Then at some arbitrary later time be able to modify the embedded Table programmatically. There is no direct way, because a GUI Table is not itself an Embedded Component with properties manageable by SetProperty, etc.

A rather complicated way to simulate such an effect might be to:
1) Have Tabulate return just the XML.
2) InsertContent of that XML (and retain a copy of it).
2) Programmatically scan that copy and substitute new column
    widths into its code, and retain this running version.
3) Embed the edited copy using the replaceid option to overwrite
    the earlier instance.

This also handles your example,

Download cmap.mw

Another workaround that I see for this problem with the maplet plotdevice is to add the style=line option to the plot command.

That can be done for all 2D plots via the command,
   plots:-setoptions(style=line):
which can be added to the start of a worksheet or an initialization file.

(That does not interfere with the default behavior of plots:-pointplot.)

You might find this less intrusive on your other computations than a workaround such as increasing Digits above 15, or setting UseHardwareFloats to false, etc, which may have broad reaching effects on calculations.

Your first attempt using solve fails because the remaining variables are not free of conditions.

You could think of it like so; solve baulks at returning a solution for T & a if there are remaining conditions on some of the other names involved.

Here are some alternatives to Rouben's natural suggestion to specify {T,a,I__cm} as the second argument to solve.

The first uses eliminate instead of solve, and it reveals a relationship amonsgt the remaining variables. (That happens to be the third equation, which here seems obvious but for other examples might not be so apparent.)

The second uses the parametric option to the solve command. Notice that if m=0 then T=0 and I__cm=0 also. In that case a can be anything, and not just g/2.

You could also specify a subset of the remaining variables as the parameters.

Download solveSysac.mw

You were already using k for the index of summation (sum call) that gets computed by f. That k was not being declared local to f. And the index name is not local to the sum call.

Then you try to use k in a wrapping seq call, as the index name. So, when seq invoked f, k takes a numeric value -- and is not free for use as an index name by sum.

You could use a different name (eg. kk) as the index name in that seq call.

Or you could change f from an operator into a procedure with local k.

Or you could change f to use add instead of sum, since in this situation add can safely use its own local instance of the index name.

For example, implementing both the second and third approaches (my preference),

Least-Squares_Fitting_in_Maple_video_ac.mw

I did the above in Maple 2019, since that was the version in which your attachment was last saved.

Usng 2D Input you should be able to simply utilize the keystrokes A__* , ie. A, underscore, underscore, *. That produces the underlying expression `A__*` which automatically gets typeset in the desired way.

If the subscipt is more complicated (than just *) you should be able to build it up in 2D Input using the Layout and other palettes.

Sometimes it may be necessary also to right-click on the input item and use the menu choice 2-D Math -> Convert To -> Atomic Variable. But that it not necessary for your example.

The attachment below shows a variety of ways to do your example in 1D plaintext Maple code.

Download misc_subscripts_1D.mw

If you want to remove overhead of doing it via an OS system call then you might consider using Maple's external calling.

You'd need to compile&link your routine to a shared library (.so or .dll, according to platform), rather than as a main executable.

Apart from removing overhead of the system call (a kind of scripting), external calling also allows inplace hardware array passing.

See the help pages for define_external and externalcalling.

Ideally, only when a procedure or appliable module is documented for users should it be called a command. In the Maple programming language "command" doesn't really have a technical meaning.

The phrase "internal command" is suboptimal, because "internal" denotes something undocumented while "command" denotes something made for users and which should be documented. Better would be internal procedure. I wouldn't be surprised to learn that I sometimes misuse that term.

None of these should ever be called function! There used to be a policy in Maplesoft's R&D that that term would not be used in documentation except for the special Maple language technical meaning as the type named function (ie. an unevaluated function call). It was a sensible policy because Maple had expressions and procedures, and it's very important for users to keep those two things conceptually separate; it's just too easy for users prone to calling both of those things "function" to become confused between those two concepts.

The word "function" also has another, quite specific, technical mathematical meaning, and also yet another common meaning in computer science. It's better to avoid the latent ambiguity.

Whether or not a procedure returns a value or not (ie. returns NULL) is irrelevant to what it should be called.

If you want one word for most of these then I'd suggest either procedure or command. (Even in the case of an appliable module the procedure assigned to the module's ModuleApply member is what gets invoked. So even there it's not so much of a stretch to use that term.)

The word restart is an exception. It could be considered as a language keyword rather than a procedure in the usual sense. And it is documented. So calling it a command makes sense. Something similar might be said for the error statement.

There's no perfect solution. As you can see, I side with your summary about the word procedure: "My inclination is to call everything for which one uses a functional call (section 3.8) as a procedure." But command is not inherently terrible, even if it lacks a tight technical language definition and can sometimes lead to ambiguity.

The word I'd advise most against using is function, because it has a technical meaning which does not match how people would often use it.

note: see also type/callable

Here is more recovery:

Regnede_Eksamenssæt_ac.mw

There might be a missing 2D Math expression, near the beginning of section (iii), in the line starting,
  "G er undergruppe af..."

I will add this to an earlier bug report of similar problems.

Somehow you've managed to get an extra, hidden Execution Group between the
   proc(ix,iy)
and the
   global T

I don't know how you managed that. I can cut&paste that procedure definition from my answer to your previous Question, into a new Execution Group, without that happening.

I notice that the 1D code appears to reside inside a Document Block, instead of the usual (single) Execution Group. I suspect that this may be the cause of the problem. I personally would only use Execution Groups (red > cursor) for 1D code inside a Document.

(See the entries in the "Insert" menu from the GUI's menubar. Or use Ctl-k as a keyboard shortcut.)