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

N := 20; 

... other code, and then,

plot3d( {seq(a[i], i=1...N)}, ... );

It's natural that a list would always be exported with one particular orientation, and it happens to be as a row.

But conversion of a list to a column Vector can be done much more easily than by using the convert command.

Try this,

Export( <X1>, "data1.xlsx", 1, "A1" );

You can insert an image from an external image file into a Rectangle within a Drawing.

You can insert the rectangle using the corresponding icon in the Drawing tool menubar (you may wish to first make the color white, to suppress the rectangle's borders). You can then select and fill that rectangle using the corresponding selection and fill (paintcan) icons, to make it contain the image from the external file.

A semicircle image can be produced by exporting a plot, or by using the new ImageTools-Draw commands.

You may need to be careful about resizing the rectangle, and matching its dimensions aspect-ratio to that of the file, in order to get a clean non-jagged curve.

It would be useful if the GUI were to allow a copy of a plot to be pasted into a selected Rectangle within a Drawing canvas.

Another approach is to use the Drawing tools menubar to draw on top of a displayed plot.

Here's an example I made using Maple 2019.1 and both of those two ways I mentioned above to produce an image file.

Download drawing_semicircle.mw

For the particular kind of polynomial expression you have, it is possible to use the sort command to alter the way in which the structure is currently stored in memory by the kernel. And doing so also forces the way it is displayed by printing. And so in this manner you can obtain what you requested.

It's possible that you will find this approach too heavy-handed, and will prefer to use the InertForm and the %-prefix operators for your display goal. But, contrary to what Carl wrote (as I read it and interpreted the claim), for your given example it is possible to control the orders of the multiplicands in the `*` terms.

Note also that since the forced sorting affects how the operands are stored then it also affects how they get accessed with the op command.

It is possible to get such an effect by applying the sort command to the whole polynomial at hand, or to get a mixed result by applying it to just a few of the individual product terms (even before calling add).

This topic is also related to the fact that Maple only stores a single instance of such product terms in memory, and for efficiency uniquifies equivalent input to the single stored representation.

Note that in the absence of such a forced sort call the default display may differ for prettyprint=3 and prettyprint=1 or 0. (There is some extra subtlety, and there are now different kinds of underlying DAG structure that can come into play, as can be seen using the advanced dismantle command.)

I've tried to illustrate some of the effects below:

Download exchangeproblem_ac.mw

Since the OP seems interested in Maple 2018,

Download RDsolve_example_2018.mw

How about using an object?

That has a constructor which you need define only once (ie. centrally). And it is supported by the type system.