I interpreted the question as being one in which the relative multiplicity of members would not matter, and that mere membership in the second list would warrant its removal. I noticed the discrepency in results and figure that the OP had made a typo.

The operation is not well defined by the provided single example alone, though it might be guessed correctly.

It seems a bit unusual to me, if the multiplicities must match exactly but the order doesn't matter.

Anyway, if I misinterpreted the question, then just ignore my answer.

@Christopher2222 You wrote, "rosettacode updates from Maple users are old and almost non-existant."

Are you suggesting that Maple users add entries? Have you contributed?

@henrylyl I downloaded a new installer for the MaplePlayer yesterday. The installer was named MaplePlayer18WindowsX64Installer.exe .

I installed it, but it does not have a restart icon on the menubar.

@Christopher2222 Well, if you don't have a definition for where some border may start or finish then chopping the eyeballed image with simple rtable indexing might suffice.

For the above code (leading up to that assignment of a procedure to `p`, one could instead have,

restart:
with(ImageTools):

img1 := Read(cat(kernelopts(homedir),"/Documents/circshift/13ydvt0.jpg")):
img2 := Read(cat(kernelopts(homedir),"/Documents/circshift/30rkxvt.jpg")):

img1,img2:=img1[1+2..-1-2,1+2..-1-2],img2[1+2..-1-2,1+2..-1-2]:
img1,img2 := Scale(img1,1..184,1..184),Scale(img2,1..184,1..184):

with(ArrayTools):
A:=Reshape(img1,[1..184*184]):
B:=Reshape(img2,[1..184*184]):

and so on. That produces this result image:

@acer After corrections mention in the bracketed update paragraph in my Answer above, I get these as the two input images and the final result.

I notice that there is a border artefact in the final result (but not so severe as when the first input image had been padded, which made the computed minimal more visually invalid IMHO). I expect that the results would be much better if any thin pure black border were first trimmed off the two input images.

@Kitonum Pardon if this is mere nit pciking, but it might be closer to exactly what is asked if the procedure itself prints the plot (and returns nothing, as asked). So, perhaps,

P:=proc(N::posint, F::appliable)
  uses plots,plottools;
  print(display(seq(seq(disk([i,j],0.1,color=`if`(F(i,j),red,blue)),
                        i=1..N),j=1..N),axes=none));
  NULL;
end:

P(7,`>`);

P(10, (i,j)->isprime(i+j) and i::odd);

@Christopher2222  It might be possible to allow the C compiler to squeeze out a bit more, by using float[4] single precision in the Compiled version. I'm not sure.

I would expect almost linear speedup on multi-core, if what I wrote were modified a bit to allow parallel computation across split partitions of Array C (ie. for subranges of the offset used, `c`). And I would not be surprised if there were another factor speedup on top of that, related to getting rid of use of `irem` as mentioned in the comment above. Who knows... the whole set of possible offsets might be handled in just a second or two. But keep in mind that 184x184 is a small image and the total time will likely grow linearly wrt both image height and width in pixels.

There should also be savings by case-splitting according to the magnitude and sign of s, i , N^2 and there differences, and thus removing the call to irem in the loop.

@mehdi jafari In Maple 17 the following behaviour can be observed in the Standard GUI: Insert a PlotConponent, set its value using DocumentTools:-SetProperty to the result of `plot(sin)`, and then extract its value using DocumentTools:-GetProperty. The extracted plot then shows with gridlines, which are now part of the extracted PLOT data structure.

The above bug can be worked around by supplying `gridlines=false` when creating the initial plot.

That bug at least in the Std GUI seems to be fixed in Maple 18.00.

@Markiyan Hirnyk ... and I did not suggest doing that for your other problem.

@Carl Love The NAG functions (d01ajc,d01akc,d01amc) accept arguments for the relative or absolute accuracy tolerance, and Maple passes something derived from evalf/Int's `epsilon` and passes it to the call_external to the NAG function.

The first few lines of this procedure indicate that epsilon may get passed as the relative tolerance.

showstat(`evalf/int/NAGInt`::d01akc);

@AndrewG The only instance I can recall of there being a Maple update which resulted in a changed build id without a corresponding increase to the point-release number shown in the product was 16.02a (see also here). That was quite unusual.

Aside from the update checker/downloader built right into the Maple Standard GUI, there is also this page which lists available updates.

@Markiyan Hirnyk I'm sorry, but I don't understand what you mean by "doubling" there. What doubled?

@Markiyan Hirnyk Thanks.

So FMI means Functional Mock-up Interface (1, 2]) then?

acer