Yes, Maple does not promise Digits decimal digits of accuracy for floating-point approximation of compound expressions. That is to say, working with d=Digits working precision does not necessarily ensure d correct digits.

See the Programming Manual. (And consider reading about the fundamentals of floating-point computation, including round-off error. These issues are not specific to Maple.)

Here is one way.

I'm not suggesting that your approach is best. I'm simply showing how it could be attained, as you've described it. I might prefer to just use just a single procedure that admitted values for both a and t as its arguments. I'm not sure what is to be gained by assigning g||k as separate procedures, except if it fits into some broader programmatic flow that you've already developed.

[edit] If your concerned with performance -- especially that following all dsolve calls -- then the best approach may depend on how many such procedures you intend on creating, and how they will be called. In some scenarios (such as a small number of discrete parameter values) you might even be better off instantiating the DE system at explicit values of the parameter in order to construct your g||k. If you utilize the parameters functionality then in your Maple 2015 it may be better to test the current parameter value, so as to not incur overhead that occurs when the parameter value is set on the fly. And some of this may relate to how you use the g||k, eg. whether ot not they are called in an interleaved manner for common t values.

Download Stack_procedures_ac.mw

You have this line, which uses squiggly-brackets (braces).

H := (-lambda+sqrt(-Omega)*{tan(sqrt(-Omega)*xi)+sec(sqrt(-Omega)*xi)})/(2*(v-1));

But {...} creates a set. You should use round brackets to delimit subexpressions.

Did you intend this instead?

H := (-lambda+sqrt(-Omega)*(tan(sqrt(-Omega)*xi)+sec(sqrt(-Omega)*xi)))/(2*(v-1));

And so,

Download syntax_backets.mw

This is to address only the errant "1" that appears as a multiplicative factor in front of the rhs expression.

It doesn't address the issue that the whole rhs fraction is rendered like (num)*(den)^(-1) instead of  num/den ie. \frac{num}{den}

Download latex_mult_patch1.mw

If it works for you then you might consider adding that to your personal initialization file.

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.