Carl Love

Carl Love

24673 Reputation

25 Badges

10 years, 58 days
Natick, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

@acer I did not submit a bug report.

Your alternate workaround did occur to me after I posted the Answer while I was making breakfast and washing dishes. Something about the sound of the sink water gets my mind "in the zone". I haven't tested it yet. If it works, it'd be far better than my workaround---something that I wouldn't rush to remove from my code as soon as this bug is fixed. 

The following procedure computes 16 significant digits of the sum in under 1 second using 31995 terms.

restart:
PS4:= proc()
local p4:= 5, P:= <1,2,3,p4>, T:= 1/mul(P), S:= 0., n;
    Digits+= 4;
    for n while S < (S+= (T*= P[1]/(p4:= nextprime(p4)))) do 
        (P[..-2], P[-1]):= (P[2..], p4)
    od;
    evalf[Digits-4](S), n
end proc
:        
Digits:= 16:
CodeTools:-Usage(PS4());
memory used=101.91MiB, alloc change=2.00MiB,
cpu time=687.00ms, real time=687.00ms, gc time=15.62ms

                  0.005929203741189040, 31995

If you use a larger value of Digits, then you'll get even more significant digits. But it takes more time of course.

@nm Although it seems quite likely that member is somewhat faster than has, that's not the main issue. The main issue is that the commands do different things, give different results. For the specific example that the OP presented, those results happen to be the same, but surely it's just a trivial example rather than his main use scenario. Compare:

A:= {b, {a, b}}:
member(a, A);
                             false
has(A, a);
                              true 

#Or perhaps this illustrates the possibly disastrous difference better:
A:= {sin(1)}:  member(1, A), has(A, 1);
                          false, true

 

Your header says you use Maple 17. I don't know whether it has the index option to max. It's easily possible that an unrecognized option would be ignored by an earlier version. Please do this test

max[index]([2,1]);

If the response is 1, then you have the option.

@Jankel So, you pop up out of nowhere (your MaplePrimes account having been created today), and your first action on MaplePrimes is to post an irrelevant Comment about an 8-year-old Answer? It seems rather suspicious.

The Question is about solving the matrix equation A.X + X.B = C where AXB, and are all square matrices of the same size. My Answer only applies to solving that unusual equation. Your example equation is trivial, and can likely be solved by any symbolic math package via a stock command. In Maple, it's done with 

LinearAlgebra:-LinearSolve(<1, 1; 2, 3>, <a, b>) 

If you have a question about solving matrix/vector equations, then post a Question.

I think that most new users overuse or over-rely on whattype. I was the same way my first few years using Maple. Now, it's been many years since I've used it at all. It's often not telling you the "complete story". It's not the fault of whattype; the problem is that a single type often cannot adequately describe an expression. In colloquial English, I'd say that whattype's response "should be taken with a grain of salt", meaning with a small amount of skepticism (meaning it requires further interpretation or investigation).

The Answer given by @dharr is also totally correct. If anyone thinks that my Answer contradicts anything that he said, then they are misinterpreting what I wrote, and they should ask for clarification.

@mmcdara The Maple 2022 result of your DoesThisWork.mw is this plot:

@nm X x X means the Cartesian product of with itself.

Although has works for the first part (in this case), it's far from optimal. Use member or in to check direct (or top-level) membership. Use has to check membership at any level.

@DJJerome1976 But note that the numbers returned are indices into the list of vertices rather than the vertices themselves. It's often true that those are the same thing because the vertex list is often [1, 2, 3, ...n(as with your example), but it's not always true.

@Brian Hanley I do understand what you're asking. As you probably know, it's commonly called "garbage collection". The steps mentioned so far (deletion of the pointer M, deletion from the display) are necessary for garbage collection, but (as you guessed) they're not necessarily sufficient. "What happens under the covers" is mysterious, has gotten more mysterious and much more complicated over the years, and, as far as I know, the complete details aren't publicly documented anywhere.

Regarding the kernel memory (not display memory), the few documented tidbits that are available can be found on help page ?kernelopts. See the subsections on bytesalloc, bytesused, cacheclearlimit, datalimit, gcbytesavail, gcbytesreturned, gcmaxthreads, gcthreadmemorysize, gctimes, heaps, and memusage. There is also the command gc(), but it only "garbage collects" items that the kernel has decided are ready to be collected, and the user has little control over that. Nonetheless, the process seems to work automatically most of the time (once the kernel "gets around to it"), provided that you delete the pointers, or use local pointers whose scope expires (e.g., locals inside procedures that aren't returned to the top level). Note that you can have multiple kernels (which run as separate processes) within one Maple session. Typically, each worksheet runs in its own kernel.

Regarding display memory---it's even more mysterious. You might be able to do something with the Java console, which I guess is documented somewhere independent of MapleSoft, but I know nothing about it. I simply recommend that large items not be displayed on screen at all.

@ I think that your Cloud suggestion applies to Maple Calculator. The OP here is using Maple Flow.

@Brian Hanley You say that you can "still click into and see the old M". This implies that is displayed on screen. In that case you should delete it from the screen (with Ctrl-Del) as well as deleting it from the "kernel" memory by one of the methods already mentioned. The simplest is M:= 'M'. The display memory and kernel memory are separate.

@ecterrab I only said that I was skeptical about it; I didn't say that it doesn't work in general. Skeptical means that I saw it as the likely cause of the error. It turns out that my skepticism was correct in this case. This is not the first time that I've encountered an error caused by using assuming real with no variables specified. (I don't remember details of the earlier case.)

Suppose I were to write a command that used keyword parameters. How would I tell assuming about those keywords? Does a mechanism for that exist?

@lcz Yes, clearly the WeightMatrix should be symmetric. I can't see the problem in your code. The first for-loop is redundant; it should be replaced by just AddEdge(gnew0, addedges). However, that is not the cause of the asymmetric matrix.

I was wrong to set any edge weights to 3. Although some edges in the resulting graph come from combining 3 edges in the original, their weight should only be 2. Edges in series through the deleted vertex do not contribute twice to the flow. But when edges originating at the non-deleted vertex are combined, their flows must be added. So change Contract to

Contract:= proc(G::Graph, e::And(set({string, symbol, integer}), 2 &under nops))
description "Remove edge from G by combining end vertices. Output is weighted.";
uses GT= GraphTheory;
local 
    V:= GT:-Vertices(G), n:= nops(V), J:= table(V=~[$n]), 
    W:= GT[`if`(op(2,G)=':-weighted', WeightMatrix, AdjacencyMatrix)](G), 
    u:= J[e[1]], v:= J[e[2]], R:= [1..v-1, v+1..n]
;
    try if W[u,v]=0 then error fi catch: error "edge %1 not found", e end try;
    W[u]+= W[v]; W[u,u]:= 0; 
    GT:-Graph(V[R], rtable(symmetric, W[R,R]))
end proc
:

The only difference is the change of 2*W[v] to just W[v].

1 2 3 4 5 6 7 Last Page 3 of 641