@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.

@Christopher2222 I specifically did not state that the reason you are having issue is because you are using Windows 7.

Your followup query was, precisely, "Can anyone or maplesoft confirm Maple 2021 or Maple 2022 is not designed for use with Windows7?"

That's what I answered. It's not one of the officially supported platforms, which I'd say is another wording for "designed for".

You should be careful about using such an approach in general, if you are replacing for subexpressions containing radicals (or trig, or RootOf, etc). If you were unlucky then you might hide a division-by-zero if some intermediate complicated denominator (involving radicals) were actually zero. An incorrect result can follow. Such a hidden zero could even bubble up to a denominator in the result.

Did you get lucky, or did your mathematical acumen let you see in advance that that would not happen for this example?

The timing is not so utterly terrible if one uses a suitable Normalizer.

restart;

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:

Ps := CodeTools:-Usage( LinearAlgebra:-MatrixInverse(KGff, method=pseudo) ):

memory used=0.97GiB, alloc change=68.00MiB, cpu time=6.82s, real time=6.45s, gc time=792.84ms

length(Ps);
                 4327

If some LinearAlgebra internal sets Normalizer to radnormal (which might be the case for this example) then this example might still be very slow. 

Another possible choice for this example might(?) be x->combine(rationalize(x)) .

ps. I don't think that I deleted the Question.

@PaulNewton Legends, labels, etc, are all part of the computed plot's structure and get shown in the Plot Component just as they do in an inline display.

(There is a very small number of things that a Plot Component doesn't respect, eg. the size option with fractional values, but almost everything else should work the same.)

I went back over your Document.

The problem with your Plot button is (as far as I can see) there is no Plot Component into which a displayPlot call can put the plot. (I also didn't see a definition of displayPlot as a procedure.) A Button cannot show its results as usual output, since there's no usual output area associated with it (its action code is not usual input of any execution group).

Attached in a revision in which I added a Plot Component, using the Components palette. It's identity is "Plot0", but you could change that property.

I adjusted the action code of the Plot button so that it sends the computed plot to this Plot Component, "Plot0", after it is recommputed and assigned to A. V8_Calculation_of_pH_from_known_values_of_Vb_(Document)_ac3.mw

Use of the name A is not strictly necessary. An alternative would be to put the calculatePlot call directly inside the SetProperty call. Here's another revision in which I did that as well as added another Button to clear the Plot Component. V8_Calculation_of_pH_from_known_values_of_Vb_(Document)_ac4.mw

The computePlot procedure must be defined before this all works, of course. You could also either:
1) move the definition of your procedures to Code Edit Regions which are set to autoexecute (upon opening of the Document), or,
2) move the definitions of your procedures to the Startup code of your Document.
In these ways you could have the Buttons function without having to execute all your Document manually. Of course I understand that this is a preliminary work, while you experiment with how things can function.

@Christopher2222 In a previous posting(by you) you already acknowledged that Windows 7 is not one of the supported platforms for Maple 2022.

There may be ways to work around that (Java setting, etc). But for this specific followup query, there is this specific detail.

@Carl Love That's great, Carl. Vote up.

(I realize that you suspect that this is where I was going with my "on-the-fly" query.)

The GUI memory issue is unfortunate. I will submit a bug report.

There are a few more tricks possible that can reduce kernel/Library side memory use here, eg. Aliases instead of temporary rtables for data passed to the plotting commands, direct construction of final PLOT structures, etc. But I doubt any of that would help with a GUI memory clog on an embedded Plot Component.

It might be possible to get around said GUI memory clog (on a single Plot Component) by actually also replacing it for each frame. One way to do that is to call Tabulate in a loop. Another is to use the insertdirect option (of the embedding streamcall) in a loop. Both are of heavier weight as a single operation, but since the individual plots are simple perhaps the time-granularity might not suffer too much. I suspect that the GUI might not perform Java garbage collection while control is still in a kernel loop operation, but who knows...

@zenterix I had an idea that you might have parallelized some of it, using Grid.

I was wondering whether it might be feasible (fast enough) to compute each frame "on the fly" and display them (one at a time) in a Plot Component. This involves not storing them all, to save memory.

@zenterix What is the end-goal for this animation with thoussands or tems of thousands of frames? Are you hoping to export it to a massive .gif file, or just play it in Maple?

If the latter, then how long does it take to compute each frame if done sequentially?

@Rouben Rostamian  That's a fantastically huge amount of memory use, just to play an animation of an arrow moving around to 1000 points on a sphere.

Memory consumption several thousand times less would be much more reasonable.

@astroverted You can store the odeplot results as entries in an Array. Then you can plots:-display those all together.

DQ4_ac.mw

@Anthrazit 

The last name evaluation of  your x["a"] results in the name a, and whattype considers the "basic data type" of that to be a table.

The last name evaluation of your x["b"] results in the name x["b"] itself, and whattype considers the "basic data type" of that to be an indexed reference. Yes, x["b"] is an indexed name (which is also a kind of name), but apparently whattype considers the indexing aspect to be more "basic".

That distinction also occurs for procedures. This attachment illustrates it more simply, I believe: whattypefun.mw

Personally I don't understand how anyone could use whattype for decent programming, even apart from last name evaluation examples.

I'm guessing that one goal might be to have it be fast and efficient/lightweight.

It's possible that floats stored in a datatype=float[4] rtable could be written over to a (reusable) datatype=integer[1] rtable, and then that could be further decomposed. I'm unsure whether that could be handled directly (by convert, etc), without muddling with sign bits.

(I recall once using a define_external to do such a raw copying of the GMP representation of float approximations of Pi as stored in Maple's memory, to get the bit representation without need for unnecessary computational conversion. Unfortunately I have little idea where I left that code... but the essence was the same IIRC, maybe tricking a BLAS scopy into doing the moves.)

Someone asked a similar Question recently, and I answered with some notes.

Writing a robust conversion utility may have a few tricky parts. In order to avoid any unwanted automatic simplification all input may have to be treated by ToInert, and I can imagine it getting complicated.