You may be referring to embedded assignment, due to my code. This is different than embedded code (code built in to embedded GUI components such as table cells). Regarding the former, I have done some small amount of efficiency testing, and I can find no significant difference in time or memory. When used judiciously, in well-formatted code, they can improve readability; if used haphazardly, they can decrease it. Let's consider my usage in this thread, which is limited to these two lines:

            
(i0:= map2(`~`[`=`], [r,theta](0), `[]`~(.75, Pi/8*~[$0..15]))), #inits
 linecolor= [seq(COLOR(HSV, .85*i/ni, 1, .85), i= 0..(ni:= nops(i0)-1))],

The first line sets the initial conditions; the second sets the colors of the corresponding trajectories. It's necessary in the second line to know how many conditions are in the first line. I could've hard-coded that in the second line, 16. But that's not robust if that number changes. The embedded assignments set up the automatic transfer of that information between the lines.

@Kitonum If you wish, the option axiscoordinates= polar can be added to any of your odeplot commands. This only changes the way that the axes, gridlines, and tickmarks are drawn; it doesn't change the curves.

You have extensively documented your problem except for the most important detail: Nowhere have you shown a complete plot3d command.

@emendes Sorry, I'm having some trouble understanding what you want to do. In particular:

• abc is a list (or set) of 3-tuples. Why 3?
• Is your exclusion criterion as I coded, i.e., nonempty intersection between a particular 3-tuple (as returned by conds(...)) and the tuples in abc?

Sets are far more convenient and a little more efficient than lists for this purpose, but if you need to use lists, that's fine.

If I understand you correctly, when a subset (or sublist) S is removed, one example should be put back. In other words, exactly one element of S should remain in the overall list. Is that correct?

And it should remain in its original position? (If no, then this can be easily achieved by replacing remove with selectremove.)

@vv You wrote:

• Please note that I have mentioned the sfloat->hfloat->sfloat conversion from the beginning.

You're right, and I apologize for not recalling that from my initial reading. No offense was intended, just ordinary academic discussion.

@Earl My mimimal understanding of the formula (which comes entirely from Weisstein, Eric W. "Gauss-Bonnet Formula." From MathWorld--A Wolfram Web Resource. https://mathworld.wolfram.com/Gauss-BonnetFormula.html) says that from the 2*Pi you must subtract the corner angles.

How do you account for the curvature at either cone's apex?

@AOdrzywolek @vv Both of you (VV and the OP) seem to be unaware of this paragraph from help page ?evalhf (where I've added the emphasis):

• The evalhf function converts all its arguments to hardware floats, computes the answer and converts the answer to a Maple float result. Hence the user never deals with hardware floating-point numbers....

In short, evalhf does not return hfloats, which is exactly what you seem to be trying to get it to do; rather, it returns sfloats.

If you want hfloats to write to your file, then put the code that creates and writes those numbers in a procedure with option hfloat. Do not use evalhf within this procedure, because even within such a procedure, evalhf still returns sfloat​​​​​​​s.

@Kitonum Indeed, one could very easily extract that numeric (x,y,z) double-loop data directly from the plot.

@lcz Like I said, there will be  no memory savings from using iterator if you save the graphs. Nonetheless, here are two ways to do it:

restart:
#
#Use iterator and save graphs by diameter--Array method
#
CountDiamterClasses4:= proc(order::posint)
uses GT= GraphTheory;
local  
    prc:= GT:-NonIsomorphicGraphs(
        order, output= iterator, outputform= graph, restrictto= connected
    ),
    d, R:= table([seq(d= Array(1..0), d= 1..order-1)]), graphmark
;
    while (graphmark:= prc()) <> FAIL do R[GT:-Diameter(graphmark)],= graphmark od;
    {seq}~(R)
end proc
:
CodeTools:-Usage(CountDiamterClasses4(9)):
memory used=11.99GiB, alloc change=0.91GiB, cpu time=2.90m, 
real time=2.57m, gc time=26.03s

nops~(%);
   TABLE([1 = 1, 2 = 91518, 3 = 148229, 4 = 19320, 5 = 1818, 
     6 = 180, 7 = 13, 8 = 1])

restart:
#
#Use iterator, and save graphs---table method.
#
CountDiameterClasses5:= proc(order::posint)
uses GT= GraphTheory;
local  
    prc:= GT:-NonIsomorphicGraphs(
        order, output= iterator, outputform= graph, restrictto= connected
    ),
    R, graphmark
;
    while (graphmark:= prc()) <> FAIL do R[GT:-Diameter(graphmark)][graphmark]:= () od;
    {indices}~(R, 'nolist')
end proc
:
CodeTools:-Usage(CountDiameterClasses5(9)):
memory used=12.00GiB, alloc change=0.91GiB, cpu time=2.90m, 
real time=2.56m, gc time=26.69s

nops~(%);
   TABLE([1 = 1, 2 = 91518, 3 = 148229, 4 = 19320, 5 = 1818, 
     6 = 180, 7 = 13, 8 = 1])

@lcz Here's a comparison of three methods for counting the diameter classes of graphs of order 9. The first uses an iterator, the second is what I used in my Answer, and the third uses an iterator and the naive list-building method, without saving the graphs. You'll see, as expected, the major benefit of iterator is a reduction in memory allocation (reported as "alloc change" by CodeTools:-Usage).

restart:
#
#Use iterator and count accumulators:
#
CountDiameterClasses1:= proc(order::posint)
uses GT= GraphTheory;
local  
    prc:= GT:-NonIsomorphicGraphs(
        order, output= iterator, outputform= graph, restrictto= connected
    ),
    R:= table(sparse), graphmark
;
    while (graphmark:= prc()) <> FAIL do ++R[GT:-Diameter(graphmark)] od;
    eval(R)
end proc
:
CodeTools:-Usage(CountDiameterClasses1(9));
memory used=11.85GiB, alloc change=36.00MiB, cpu time=2.41m, 
real time=2.41m, gc time=4.41s

TABLE(sparse, [1 = 1, 2 = 91518, 3 = 148229, 4 = 19320, 5 = 1818, 
  6 = 180, 7 = 13, 8 = 1])

restart:
#
#Use direct generation of graphs:
#
CountDiamterClasses2:= proc(order::posint)
uses GT= GraphTheory, LT= ListTools;
    nops~(
        LT:-Classify(
            GT:-Diameter, 
            [GT:-NonIsomorphicGraphs](
                order, output= graphs, outputform= graph, restrictto= connected
            )
        )
    )
end proc
:  
CodeTools:-Usage(CountDiamterClasses2(9));
memory used=11.95GiB, alloc change=1.00GiB, cpu time=2.90m, 
real time=2.47m, gc time=32.62s

   TABLE([1 = 1, 2 = 91518, 3 = 148229, 4 = 19320, 5 = 1818, 
     6 = 180, 7 = 13, 8 = 1])

restart:
#
#Use iterator, but also use naive method of building lists inside loop.
#
CountDiameterClasses3:= proc(order::posint)
uses GT= GraphTheory;
local  
    prc:= GT:-NonIsomorphicGraphs(
        order, output= iterator, outputform= graph, restrictto= connected
    ),
    d, R:= table([seq(k=(), k= 1..order-1)]), graphmark
;
    while (graphmark:= prc()) <> FAIL do R[GT:-Diameter(graphmark)],= 0 od;
    (nops@`[]`)~(R)
end proc
:
CodeTools:-Usage(CountDiameterClasses3(9));
memory used=126.32GiB, alloc change=66.64MiB, cpu time=5.79m, 
real time=5.92m, gc time=30.47s

   TABLE([1 = 1, 2 = 91518, 3 = 148229, 4 = 19320, 5 = 1818, 
     6 = 180, 7 = 13, 8 = 1])

@AOdrzywolek Why do you want to "export" results in "binary"? "Export" implies that the file is meant to be read by some other program. What is this primitive program that can't read normal ASCII data?

@lcz The code that you posted in your Question was saving every graph generated into one of the lists. Since all the graphs are saved, there is no memory benefit from using the iterator. If instead you simply wanted to count the graphs of each diameter, or do anything else other than save them, then you can benefit from the iterator.

The reason that your code took more time has nothing to do with the GraphTheory package. It took more time because you were building lists inside a loop. In Maple, that's extremely inefficient, and you should never do it. Instead, you should build an Array or table inside the loop, and if needed, convert it to a list outside the loop.

@emendes Putting [] after a list or set (only those!) returns the underlying sequence, equivalent to op(...). The syntax allows [] to be put after almost anything, but unless it's a list or a set, it mostly does nothing other than create a mess. 

Well, clearly this one wasn't removed, so it's not automatic.

The most common reason for removal is duplication, i.e., the same question or a too-similar question asked by the same user.

It is often I who removes them, but I don't recall removing any of yours. Anyone with a reputation over 500 can moderate this forum.