It does not necessarily follow that y1 has been assigned an expression sequence with seven elements.

Upload a worksheet that replicates the issue, or at the very least show us what lprint(y1) gives.

@Mike Mc Dermott The Matrix help page's Description bullet point for that calling sequence does not match your expectation.

Which documented calling sequence of the Matrix command are you considering, when you refer to the third argument as the "initial value"?

@sursumCorda My main point was that is and coulditbe are the primary commands under which I'd hope first to find this functionality. But I was mostly getting FAIL.

I am planning to submit a software change request against them here. I would add in a note that SMTLIB might be better leveraged to improve their functionality (though, doing so would require adjustments to the case-switching and dispatch mechanisms, which might be involved).

After is and coulditbe, it's possible that simplify might also be able to leverage it.

In all of this it might be that and/not/or might be handled before, say, &implies. I'm not sure how much more involved it would be to support the logical implication via assuming, as opposed to a logical equivalent of and.

@MigMRF One idea is that you could try doing what I (and many others) do, and avoid using 2D Input altogether. I use 1D (plaintext) Maple Notation in a Worksheet, and not 2D Input in a Document.

Do you inline images in your Documents? Do you use a foreign language in it (eg. Danish). That pair, combined, neems to be a common theme of corrupted Documents as reported in this forum.

As far as you attachments go, it's tricky for me to know what you actually enter (as 2D Input) in the input areas whose equations might become corrupted.

I suppose that it needs only half as many variables, and fewer conditionals than I had earlier. (It was early, no coffee.)

sat_fun2.mw

restart;
M := Matrix([[1,9,6], [1,9,-4], [6,1,-9],
             [4,-3,-1], [7,1,-9], [6,5,7],
             [8,5,-3], [-7,-1,3], [6,-5,-8],
             [5,-8,-7]]):

S := &and(seq(&or(seq(`if`(M[i,j]>0,
                           s[M[i,j]], not s[-M[i,j]]),
                      j=1..op([1,2],M) ) ),
              i=1..op([1,1],M) ) ):

ans := Logic:-Satisfy(S);

   ans := {s[1] = false, s[3] = false, s[4] = false, s[5] = false, 

     s[6] = true, s[7] = false, s[8] = false, s[9] = false}

DocumentTools:-Tabulate(M, widthmode=pixels, width=100, fillcolor="LightGray",
                        fillcolor=((v,i,j)->`if`(eval(`if`(M[i,j]>0,s[M[i,j]],not s[-M[i,j]]),
                                                      ans)=true,"Green","Red"))):

This smaller set of equations places less burden on, say, using BooleanSimplify here, or interpreting its results.

This is a bit of fun, using the above S:

with(Logic):
SS:=BooleanSimplify(S):
`if`(op(0,SS)=`&or`,
     map(print,subsindets(subsindets([op(SS)],indexed,op),
                                     specfunc(`&not`),u->-op(u))),
         SS):

The top-most solution printed by that code is,
    ((1 &and 6) &and (-3)) &and (-7)
which indicates that for this particular Matrix the button-pressing game can be solved in only four presses, on 1, 6, -3, and -7. 

@MigMRF I usually repair these using the vi text editor to open the XML .mw file as plaintext, in an OS terminal. I try to close off XML elements or remove invalid ones (striving for minimal loss).

In this case there were no unclosed elements, but there was one invalid Equation element. I just removed that single element. You would not know that this element was invalid just by looking at it. It was valid as XML. But it did not represent what the Maple GUI expected, and I happen to understand that.

If lucky then you might get a relevent message set from the Maple GUI to the terminal console that opened the .mw file, for hints as to location of the first problem.

So, if lucky then it's enough to know how to close off errant XML elements with minimal loss. If unlucky then knowledge of the structure of those elements (from the point of view of how Maple's GUI interprets them) might be necessary. This case was the latter.

If all this makes sense to you, then you might be able to do it yourself.

In contrast, the GUI seems to work from the outside in, removing all Sections that don't have any problems. Or something like that. This often leads to considerably more loss of content when recovering, compared to what I described doing.

@PaulNewton What dharr wrote about fi being "no longer documented" is not true.

The last bullet point of the Description of the help page for Topic if reads (italics mine):

"The end if that terminates a selection statement can be shortened to just end, or the ALGOL-like fi, if desired."

There is also a bullet point in the Description of the Help page with Topic do that reads:

"The end do that terminates a repetition statement can be shortened to just end, or the ALGOL-like od, if desired."

This looks interesting, and I'm looking forward to trying it out. Alas, it's a very busy time of year.

@Carl Love Sorry, I overlooked that you had removed the need for additional plotting calls, and had Aliased the Matrix in Frame. A tiny bit more overhead might be avoided, I think, by using BlockCopy instead of :-Pts[..,k]^+ which I suspect forms a pair of (collectible, transient) Vectors for each frame.

I think we agree that the kernel/Library side is already fast, and the bottleneck(s) are in the GUI. I don't know if a GUI/java garbage collection can be triggered -- or, that what prevents it could be avoided. I'd like to try the pair of ideas I mentioned, about clobbering the Task Region's embedded content rather than dispatching plots to a permanent Plot Component.

Wasn't your file called "Dissociation Constants.m" before?

But now you seem to be looking for "Dissociation constants.m", with "constants" not capitalized.

Your second Document works, for me, if I point it to the name of the file from your previous Question. At the end I get the Matrix assigned to the name DissociationConstants.

@PaulNewton I toggle the Mapleprimes editor into Source mode (from its menubar), and then in the raw HTML I add  <pre> ... </pre> tags.

For example,

L1 := "Methionine = (S)-2-amino-4-(methylsulfanyl)-butanoic acid (2.13)":

StringTools:-Take(StringTools:-Drop(L1,"("),")");

               "2.13"

ps. If StringTools bindings are already in effect, and you know that you'll have several examples with the same general form, then the following is pretty simple:
    Take(Drop(L1,"("),")")
In comparison, using complicated regular expression matching looks needlessly complicated here.

@sursumCorda I don't really undertstand your followup use of the word "Strangely", since I did not state that there was always a way around such issues.

I also don't really understand your followup query, "Any reason?", since everything has a reason (or nothing does).

It happens that your followup can get lucky with an alternate that I mentioned, of doing it one variable at a time.
   minimize((x - y)^2 - k*x*y, x=0..infinity) assuming k>0, y>0;
   minimize(%, y=0..infinity, location) assuming k>0;

(This is not a guarantee, in general. It's not especially interesting to come up with more examples that demonstrate the weakness in the command -- unless you can use that to delineate or characterize exactly when the command would work, or when variants would work, etc.)

@Christopher2222 Why didn't you add all this to your older Question thread on this topic (made seven months ago), instead of spawning this new thread (without even cross-referencing)?

As you're ok with editing Question names then you could just as easily have adjusted the older one to reflect both.

You even made another duplicate of that older Question thread, which was deleted.

Taken all together, you're spamming this site.

@mmcdara Below I use Maple 2015.2, and keeping the `.` (considering E__c and the W[i] as possibly being Vectors/Matrices).

It is I who sets Normalizer to evala (...apparently a better choice that radnormal).

restart;

kernelopts(version);
   Maple 2015.2, X86 64 LINUX, Dec 20 2015, Build ID 1097895

KGff := Matrix([[1/3000*D__pile*(W[1].E__c)+1/63368*D__pile*(W[2].E__c)*89^(1/2),
                -1/63368*D__pile*(W[2].E__c)*89^(1/2),
                -1/39605*D__pile*(W[2].E__c)*89^(1/2), 0, 0],
               [-1/63368*D__pile*(W[2].E__c)*89^(1/2),
                1/63368*D__pile*(W[2].E__c)*89^(1/2)+1/1000*D__pile*(W[3].E__c),
                1/39605*D__pile*(W[2].E__c)*89^(1/2), -1/1000*D__pile*(W[3].E__c), 0],
               [-1/39605*D__pile*(W[2].E__c)*89^(1/2), 1/39605*D__pile*(W[2].E__c)*89^(1/2),
                8/198025*D__pile*(W[2].E__c)*89^(1/2), 0, 0],
               [0, -1/1000*D__pile*(W[3].E__c), 0,
                1/1000*D__pile*(W[3].E__c)+1/63368*D__pile*(W[4].E__c)*89^(1/2),
                -1/39605*D__pile*(W[4].E__c)*89^(1/2)],
               [0, 0, 0, -1/39605*D__pile*(W[4].E__c)*89^(1/2),
                8/198025*D__pile*(W[4].E__c)*89^(1/2)]]):

Normalizer := evala:

new := subsindets(KGff,`.`,u->content(u)*freeze(u/content(u))):

temp := CodeTools:-Usage( LinearAlgebra:-MatrixInverse(new, method=pseudo) ):
memory used=1.00GiB, alloc change=68.00MiB, cpu time=6.66s, real time=6.34s, gc time=751.05ms

Psnew:=expand~(thaw(temp)):

length(Psnew);

                 3618

I'll note that both,
    expand~(evala( KGff.Psnew.KGff - KGff))
and,
   expand~(evala( Psnew.KGff.Psnew - Psnew))
return as the 5x5 zero-Matrix, in accordance of the pseudo-inverse definition.

note: Upon digging, it may even be that an internal LinearAlgebra routine is setting Normalizer to this, as automatic default:
    Normalizer := proc (a) local s; s := series(norml(a),t,2); convert(s,polynom) end proc;
I don't really understand why that is so. I set Normalizer above as an attempt to avoid any default setting(s) for it.

A typical way that Normalizer and Testzero get used in, say, LUDecomposition, is for guarding against accidentally using any hidden-zero as a pivot (ie. for division), and for reducing expression swell upon pivoting.

By the way, my comments about the danger of lurking hidden-zeroes was meant because of the radicals. Without adequately strong zero-testing of candidate denominators (eg. pivots) a lurking hidden-zero timebomb can be accidentally introduced. With mixed concoctions of arithmetic expressions with radicals present, an adequate algebraic normalizer is generally needed to avoid such.

I originally wasn't considering things like W[i].E__C as possibly being a singular Matrix or what have you. I assumed that those blocks are supposed to be nonsingular, and above I froze them temporarily.

note: Typesetting:-delayDotProduct was originally a way for the 2D typesetting mechanisms to represent a `.` (used, say, inside a 2D Input procedure definition). A bit like a placeholder. But nowadays... it seems to mostly be crufty crud that shows up when people try and paste their output into this forum.