22120 Reputation

29 Badges

15 years, 222 days

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by acer

@John2020 Please don't submit it as another, separate Question thread.

@Carl Love I do not prefer that mechanism using ToInert,specfunc,pointto because it has less direct connection to the nature (or location or details) of the mystery procedure.

Your comment about reliance on opaquemodules=false is not really an accurate description of that code. I favor a mechanism, where that doesn't setting come into play if unrelated; it's not needed for the routine to be accessed at runtime, so a mechanism to reveal it independent of that setting is less kludgey.

Also, your comment about results from LibraryTools is not very on target here, since it describes far more usual procedures than the very special case considered here for partition1.

Please don't repost this in an entirely separate thread. If you still want an iterative process then you can put any followup details or worksheets in Replies/Comments here.

@vv The procedure can be part of the lexical table because of how Maple internally stores procedures and references.

An example of how this might arise, for fun:


M := module() export foo;

   # The following is an anonymous module, that is
   # neither a local nor an export member of M.
   module() local hidden1;
      # Here is an assignment to foo, an export of M.
      foo := proc(x) cos(x) + hidden1(x); end proc:

      # Here is an assignment to hidden1, a local of
      # this anonymous module.
      hidden1 := proc(x) sin(x)^2; end proc;

   end module;

end module:




proc (x) cos(x)+hidden1(x) end proc

eval(hidden1);  # nope


eval(M:-hidden1);  # nope

Error, module does not export `hidden1`


blah := [op(7, eval(M:-foo))]

[_thismoduledefinition, module () local hidden1; end module, hidden1, hidden1]

map(eval, blah[3..4]);

[hidden1, proc (x) sin(x)^2 end proc]



I don't know why combinat:-partition and partition1 are organized as they are. It might be a coding choice of whoever converted combinat from an older table-based package to the more modern module-based package. But I don't know whether that was a stylistic choice or based on some functionlity/compatibility need.

@vv The partition1 procedure called inside the combinat:-partition procedure is referred to in the lexical table of the latter. It can be  by examined via the 7th operand of the procedure assigned to combinat:-partition. Eg,

foo := [op(7, eval(combinat:-partition))];
map(eval, foo[3..4]);

You could also step into partition1 by running a call to combinat:-partition in the debugger and then issuing the debugger command list 1..10 to see all its lines of code.

If you'd like I can show a small example of a way to construct such an "anonymous" reference.

@tomleslie I used Maple 2020.2 for 64bit Linux. I did that because one of the OP's very recent Questions was marked as Product=Maple 2020.

That code runs and takes 3.5sec to produce the animation and a separate and additional 45sec to render its first frame -- in a fresh GUI session with no prior output -- in Maple 2020.2 for 64bit Linux.

If I rerun without first removing prior output then it takes about 100sec for the additional rendering to appear, as measured by the time[real]() difference in a later, separate Exceution Group as well as my wristwatch. This also emits errors to the terminal from which I launched the GUI, including "java.lang.OutOfMemoryError: Java heap space" and "GC overhead limit exceeded". That's where I got my reported timing from.

If I rerun yet again it gets then it appears to stall, and the animation does not appear even after a very long amount of time. Eventually I have to kill the GUI process. The launching terminal is filled with repeated "Java heap space" messages.

If I do the whole experiment in Maple 2021.0 for 64bit Linux then it takes 3.8sec to construct and only an additional 9.4sec to render the first frame in a fresh session with no prior output. Upon repeat, with prior output present, it then takes 9.2sec for the first render.

The JRE bundled with Maple was updated for Maple 2021.0. The Maple Standard Java GUI performance in the this example is improved. But 9sec is still far from acceptable as time to render the first frame. And it gets worse still, as the grid size is increased past the quite modest [91,91].

So I stand by what I wrote before, about high resolution densityplot animations being an inferior methodology if the number of frames is not small.

Java memory performance and management might have improved in Maple 2021.0, but whether at 3 or 4 or 9 seconds for rendering it's still very poor for this modest resolution densityplot animation example. A good system would render the first frame in less than 1/10th of a second.

Tom, there is no need for aggressive statements of disbelief, just because someone else's experience differs from yours.

In the absence of code or a worksheet that can fully reproduce the problem it is not possible for anyone else to discern exactly what was going on.

@mmcdara Yes, the original error message is clear, as it shows,

   0 = 0 = .. (1/2)*Pi

so theta on the LHS evaluated to 0.

The OP may not have properly unassigned and rerun, except after also trying evalf (a red herring except possibly in ancient versions).

The OP also writes lowercase pi a few times in this thread. Such typos hint that extra care might be needed.


@Earl This is not the cause of the user's problem.

It is not necessary to evalf the range's end-points.

They can be of type realcons, and if not already of type numeric then the animate command will do the evalf automatically.

You should inform us precisely as to how you want the "cells" to be colored.

Should they each have a distinct color but be individually shaded uniformly? Should there be a pattern, across the whole? Or should they be shaded in some gradient manner?

@mmcdara The OP wrote, "...I need to read the numbers on the right which belongs to this combination."

I take that as meaning something different from the need to read the row for each match of the combination, more generally.

It's less efficient to use SearchAll if only membership need testing, which might manifest at a larger size example.

Of course, we weren't informed whether the OP has other examples with duplicate occurences which are suppose to all be matched (with the rows duplicated correspondingly).

@Ronan Kitonum has kindly shown how you can utilize inert `%*` for the products of the factorials.

You wrote, "I didnt realise % made operations inert.  I haven't seen that in the help or at least I have found that."

In your original code you were trying to utilize the command NoSimpl from the InertForm package. Sorry, I got the impression that you would have read the Help pages for that package, which is why I didn't explain my use of %.

If you look at the Help page for the InertForm package you can see this as the second bullet point in its Description section,

    The inert form of an expression is a representation that avoids evaluation
    and automatic simplification by changing operators and function names
    to unassigned symbols prefixed with a % character.  For general information
    on inert functions, see

Also, you are right, there is a quirk, such that the inert %factorial calls are shown as regular blue output (with bold, blue, postfix exclamation marks) regardless of whether inert=true or inert=false is passed to InertForm:-Display. I had already noticed that but didn't mention it because the inert=false does still affect whether any `%*` gets rendered in gray or blue. I suspected that you might also want the `%*`. (This quirk about %factorial is not currently mentioned in Carl's lengthy Answer.)

@mapleatha There are instructions on the Help page for the animate command,  about making the animation play.

@Pepini That's nice to see.

As mentioned before there can be some GUI sluggishness with high resolution densityplots, which was part of my motivation years ago to get better performance using images (hardware float Arrays). In some older Maple versions the Java JRE was even slower and more memory hobbled, and the Maple GUI densityplot responsiveness more severe.

The GUI does a bit better now, but FYI here's some history:

You cited an old (2019) Question in which I gave this Answer:

That in turn has a link to a much older (2011) Post of mine:

I wrote that partially to deal with some examples set in this (2011) Question:

And that Question cited the following (2011) article, one of whose authors wrote the book you mentioned:
   Phase Plots of Complex Functions: A Journey in Illustration


@Pepini You're welcome.

You can increase the resolution by passing the grid option to the plot3d command, which I showed earlier.

For example,  grid=[201,201]

Note that if you make the grid very fine then the GUI becomes sluggish upon manual rotation of the 3D plot using the mouse. In such cases it can serve one better to figure out an acceptable fixed orientation and pass that in.

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