Have a look at the ssystem or system commands (or the variant system[launch] ).

Arguments to execute a command can be passed.

If you need to handle a particular example, then tell us the full details(!).

Each time through the loop your code assigns to theta, which wipes out all the previous assignments to indexed theta names.

You could simply change name, for either all the unindexed references, or all the indexed references, to avoid this collision.

seqQ_ac.mw

The attached worksheet overlays a rendered POLYGONS structure with colored pairs of line segments between adjacent points in the list L (with wrap-around connecting L[-1] and L[1]).

You can execute the whole worksheet and then drag the red circle around, inside the axes box. This is done using the Explore command in Maple 2019.1.

The ensuing result seems to agree with what I believe Tom was conveying. The total shaded area is the additive accumulation of shaded polygons whose edges share a common interior coloring (winding parity, or whatever you'd like to call it).

polygonstructureshading.mw

(I cannot properly embed this worksheet here, as Mapleprimes does not support Explore output.)

It seems to balk at the trivial range t=0..0 beng supplied to odeplot.

So, you might animate starting from a small positive value, or add a conditional case to frame.

[edit] I have added examples of each of my previous suggestions below, using Maple 2019.1.

 The first suggestion, to use a non-trivial range, can be done by adjusting either the odeplot or the animate call's range argument. I chose to adjust the range in the odeplot call, so that the paraminfo (running value of animating parameter t) still displays precisely as t=0. in the first frame.

Download mw_ac.mw

ps. I would consider the failure of odeplot in the case of a trivial range (singleton point) to be a bug, and I will submit a bug report.

You could consider this as an example of premature evaluation.

The plot command is seeing just ceil(x) as input, and the `mod` aspect has been dropped prematurely.

That can be resolved in the usual ways: 1) delayed evaluation via right-quotes, or 2) plotting via operator form, or 3) a specialty procedure that returns unevaluated when passed a non-numeric (symbolic) input.

In this situation, choice 3) can be implemented using the extension mechanism of `mod`, rather than the approach of constructing and using a wholly new procedure name.

Download ceilmod.mw

These are not the only ways to resolve this.

No, it cannot be changed in the way you're describing (over and above whatever basic toolbar effects that are your overall Desktop look&feel).

How about

seq(print(seq(...))):

What you seem to be referring to as the "arguments" of an object is not something that necessarily exists in the created result in any uniform manner.

It just so happens that several examples of objects have a ModulePrint which shows what's been stored. Some even have a ModuleDeconstruct.

But in general an object need not store the constructor's passed arguments in any particular way.

I suppose that an object might not store them (or a result of computing with them), anywhere. Although I cannot offhand imagine a useful purpose for such an empty object.

I think that this problem is related to the concern that the denominator is converted as a multiplicand (raised to power -1), rather than being handled with \frac{}{}. The effect is that the resulting LaTeX doesn't look good.

Here is the rendered LaTeX produced by latex(sol). We can observe that not only is there a strange multiplicative factor 1, but the whole thing is quite wide because of how the denominator is handled.

And here is the rendered LaTeX as produced below,

Similar problems with the strange factor 1 can occur when trying to force "inline" math with a small value, say by setting a small value for Maple's (undocumented) _LatexSmallFractionConstant variable.

So one possibility might be to try and split the rhs (a long symbolic fraction), latex its numerator and denominator separately, and then conjoin. This would allow the use of an injected \frac{}{}, if appropriate.

This is just a prototype of an idea, on which I spent little time. I'm sure that several people could easily implement it more robustly. I did not use numer and denom because those expand. But if you're willing to accept a simplified result then it'd be more robust to use numer and denom (and simplify) than my call to selectremove below.

Note: you have a slight history of applying people's code in cases where it (clearly, IMO) does not apply. I'm not going to make the following code fragment bullet proof. If you cannot understand what the code does then you probably shouldn't use it. It's not complicated.
[edit] I mean that the code below is not complicated. The question of when the problem occurs, and how to fix it more generally, may be complicated. It might even be more productive to find how the latex procedure does this thing, and somehow disable it.

Download latexfracproto.mw

I agree that the latex command needs a thorough overhaul.

If UseHardwareFloats=false or (UseHardwareFloats=deduced and Digits>15) then the elementwise operation on the float[8] Vector will try and produce a float[8] result Vector (ie. if the results are numeric).

So the rounding action can succeed, but putting the results back into a new float[8] Vector turns the integers back into floats.

In contrast, regular map does not do that preservation of the float[8] datatype.

As for your second question, T does not have a float[8] datatype, so neither does the result from round~(T). So the rounded results don't get inadvertantly turned back into floats.

Download round_float8.mw

If you know which names are relevant (or, here, the relevant indices) you can construct a sequence of assumptions using the seq command.

k[1] := 16:

solve(k[2]^2=k[1],{k[2]},useassumptions)
  assuming seq(`if`(not assigned(k[i]),k[i]>0,NULL), i=1..2);
                                    
               {k[2] = 4}

seq(`if`(not assigned(k[i]),k[i]>0,NULL), i=1..2);

               0 < k[2]

Alternatively,

solve(k[2]^2=k[1],{k[2]},useassumptions) assuming positive;

                 {k[2] = 4}

Another variant,

restart;

k[1] := 16:

expr := k[2]^2 = k[1]:

myassumps := seq(v>0,v=indets(expr,And(name,Non(constant))));

           myassumps := 0 < k[2]

solve(expr,{k[2]},useassumptions) assuming myassumps;

              {k[2] = 4}

You could also refine that indets call to get only the names upon which expr depends (ie. no dummy variables, etc). Or you could extract only the indexed names. Out of habit I used And(name,Non(constant)) in the above call to indets in order to sieve out names like Pi, not because you have k[1] assigned.

Technically, the names k[1], k[2], etc are indexed names. They just happen to pretty-print with subscripts in 2D output.

The base SI unit for temperature is K (kelvin). And so that is used by default when combining expressions with mixed units. If you want to change that behavior you can use the Units:-UseUnit command.

You can add relative temperatures (increments), where 1 C = 1 K. If you want to add absolute temperatures -- say, for the purpose of averaging -- then first convert each as temperature.

Your other combine examples (eg, with Units(m) for meter) just happen to use the base SI unit in the first addend. The resulting unit came from the SI base unit for the given dimension, and not because of what was in the first term.

Download temp.mw

Your attempted workaround using sign(op(1,expr)) will also throw an error or go wrong for several other kinds of example. For example it will go wrong for a product where the first multiplicand is something that sign throws an error (such as in your earlier examples).

I suggest using frontend to discern what you're after -- acting on the first operand in the case of a sum, but otherwise freezing all but products.

I think that this is conceptually simple: a typographically leading minus sign is due to a negative multiplicand (possibly on the leading term of a sum). Hence the targeted freezing.

Download sign_frontend.mw

In 2D Input mode you can enter those using items from the (right panel) Layout and Accents palettes.

I am guessing that you want to see the + symbol appear on the +infinity tickmark.

You could simply change the quotation marks (double quotes) around -infinity and +infinity in your 2D Input example to be single left-quotes (name quotes).

In 1D Maple Notation (plaintext) those could be entered as `-∞` and `+∞` .

Download TickmarkQuestion_ac.mw