@Christopher2222 Where it utilizes Today you can instead modify that using AdjustDateField.

Tod := Calendar:-Today():
New := Calendar:-AdjustDateField( Tod, "minute", 10 ):

Calendar:-Format(Tod, "hh:mm:ss a");
Calendar:-Format(New, "hh:mm:ss a");
                         "01:46:55 PM"
                         "01:56:55 PM"

clock_adj.mw

The original question was defaced. It went something like this:

"Does anyone knows how to calculate determinant of a matrix with a proc or function , i mean i don't have to use "det" in maple i need a whole..."

And the original title was, "Help me with determinant calculation of a matrix".

What is the class of optimization problems in which are you interested?

@mmcdara 
Just as a fun alternative,

Download for_fun.mw

Of course your mileage may vary, depending on expression.

I recall that (7.5 years ago) I wrote this.

I'm pretty sure that I've duplicated a similar thing (that also adjusts colors of fencing, etc) in several responses over the years.

It's all inter-related: MathML, Maple's Typesetting, etc.

However none of this helps directly with your original question (unless you are willing to accept a space denoting multiplication of H__2 or H[2] and O__2 or O[2], or to remove it in such mechanisms).

Even Robert's suggestion to manually form the concatenated name of a pair of symbols -- both having subscripts -- as an atomic identifier is not entirely straightforward. Backing up over a space between subscripted terms may be one step. Obtaining a result with upright Roman symbols is yet another step. And all as a one-off.

One of the strengths of a programming language is that such constructs can be built programmtically.

Download typemk_more.mw

@mmcdara If you lprint your example you should be able to detect that your problematic example has some hidden character or space in it.

@Axel Vogt It may be that inttrans:-fourier is splitting it, and then running into failure:

int(erf(x)*exp(-I*x*k),x = -infinity .. infinity):
lprint(%);
  -2*I*exp(-1/4*k^2)/k

int(erf(x)*cos(-I*x*k),x = -infinity .. infinity):
                     0

I*int(-erf(x)*sin(-I*x*k),x = -infinity .. infinity):
lprint(%);
  I*int(I*erf(x)*sinh(x*k),x = -infinity .. infinity)

The integrals involving erf(x)*cos(-I*x*k) and erf(x)*exp(-I*x*k) are handled successfully by method=meijergspecial.

This is an engaging read.

Readers who like this might also be interested in these old posts by John May: 1, 2, 3, 4, 5, 6.

@Magma I do not have access at this momemnt to a machine with enough RAM to complete your large example.

However, I have noticed something troubling about the performance on your smaller example (which I included in my first Comment) as shown by CodeTools:-Usage under 10 repeats.

Maple 2015.2 (or earlier, approx.)
Your BP:
memory used=41.43MiB, cpu time=229.70ms, real time=232.80ms, gc time=12.40ms
Carl's modified BP:
memory used=12.47MiB, cpu time=97.80ms, real time=97.80ms, gc time=4.41ms

Maple 2016.0 (or later, approx.)
Your BP:
memory used=193.62MiB, cpu time=1.03s, real time=990.50ms, gc time=96.95ms
Carl's modified BP:
memory used=152.51MiB, cpu time=783.60ms, real time=757.30ms, gc time=76.69ms

@Magma In order to get Carl's revised BP to behave the same (on the earlier example A) as your procedure BP in Maple 15 all I had to do was modify one instance of a call to seq (to not utilize the newer calling sequence seq(U) ).

Otherwise I simply copied and pasted as 1D input.

BP_15.mw

Did you have an (other) input example that was problematic?

@Christopher2222 In my opinion the iPhone is a far more interesting target than the Fire for an Arm port.

The Fire also has difficulties with installation of arbitrary programs as applications. That also applies (at present) to an x86-64 based Chromebook, although there is some mitigation for those who run a terminal shell in developer mode or who re-install with ubuntu, etc.

Another Arm platform that might interest some is the Raspberry Pi.

On a related topic, I am hoping that the worldwide cloud/thin-client craze will peter out, and that something as locally useful as plugins will re-emerge.

@Kitonum Indeed, all methods will suffer from the possible problem of prior uniquification by the kernel. Your last edit is another example of what I was showing: forcing the order in which the variables are used to complete-the-square is enough (but still will succomb if the unwanted form has been previously constructed).

Unfortunately I don't know how sort could be used to forcibly re-order the terms (as for some similar problems) because the target is not expanded.

Download zw2.mw

@Kitonum Your approach is not generally reliable -- it doesn't work if the alternate form has been formed beforehand in the same session.

Given the above weakness (to which Carl also alluded), there are easier ways to get the same effect.

Download zwisch.mw

@vv The persistence of those plot labels (up until output removal) in your example is intentionally designed GUI behavior, as I explained previously in my Answer. I do not much like that behavior, but it's neither new nor very mysterious.

Yet what is indeed buggy is that, in the OP's original example, axis labels from one plot got applied to another within the same execution group.

I conjecture that this might be an overlooked corner-case is the logical flow of the GUI code that handles "plot persistence". It might also relate to use of semicolons on assignment statements involving plots.

@mmcdara That's quite a different mechanism.

Plot inheritance (aka plot persistence) affects output of single execution groups (or document blocks) independently. It consists of the GUI automatically re-applying certain display qualities from a prior plotting output upon re-execution of the very same group/block. The effect does not transfer between groups/blocks. It can be cleared by removal of the output of the particular group/block.

What you're describing now is that interface settings are managed by the GUI (I for Interface) and within a GUI session are not reset by a restart. That affects multiple groups/blocks together.

It is somewhat related to the unfortunate fact that calls to interface should go in a separate group/block from calls to restart.