It works for me (Maple 13, Linux 64-bit):

> with(ImageTools):
> img:=Create(20,20):  
> img[2,2] :=.98:
> img[2,2]*4 = .98 * 4;
                                             3.920000000 = 3.92
 

The second is the "true" bogosort. The comparison is pointless.  Bogosort runs at O(n!), so you won't be able to sort a list with more than about 10 items. Bubble and cocktail sort should be O(n^2). Neither are good algorithms, but they aren't intentionally bad.

The second is the "true" bogosort. The comparison is pointless.  Bogosort runs at O(n!), so you won't be able to sort a list with more than about 10 items. Bubble and cocktail sort should be O(n^2). Neither are good algorithms, but they aren't intentionally bad.

That works only because the solution to both x^2 and sin(x) is 0.  That is, to see what is happening do

 {map(%solve, x^2-sin(x),x)};
                              2
                     {%solve(x , x) + %solve(-sin(x), x)}

That works only because the solution to both x^2 and sin(x) is 0.  That is, to see what is happening do

 {map(%solve, x^2-sin(x),x)};
                              2
                     {%solve(x , x) + %solve(-sin(x), x)}

You are referring to the last bullet in the Description section of ?colondash. That is awkward. I assume that it originated when modules were first introduced so that a lot of packages were still table-based. Not many remain (they are listed at the bottom of ?index,package).

You are referring to the last bullet in the Description section of ?colondash. That is awkward. I assume that it originated when modules were first introduced so that a lot of packages were still table-based. Not many remain (they are listed at the bottom of ?index,package).

Sectioning the board into cells and detecting which is which is not hard, I've written code to do that.  I was wondering whether the OP wants to retain the history, i.e. the stone numbering.  That would require use of an external OCR program. 

Sectioning the board into cells and detecting which is which is not hard, I've written code to do that.  I was wondering whether the OP wants to retain the history, i.e. the stone numbering.  That would require use of an external OCR program. 

There should be either a description or example of that in the relevant Maple help page (presumably ?parameter_classes). It would be difficult to deduce that that was necessary otherwise.  Possibly one might figure it out be dismantling the procedure and noting that y only appears in the parameter sequence.

For example,

dismantle(proc({y := 3 }) 'procname'('y' = 2) end proc);
PROC(10)
   EXPSEQ(2)
      ASSIGN(3)
         NAME(4): y
         INTPOS(2): 3
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   FUNCTION(3)
      PARAM(2): [-2]
      EXPSEQ(2)
         EQUATION(3)
            UNEVAL(2)
               PARAM(2): [1] <- this is the local y
            INTPOS(2): 2
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   BINARY(2)
      0

There should be either a description or example of that in the relevant Maple help page (presumably ?parameter_classes). It would be difficult to deduce that that was necessary otherwise.  Possibly one might figure it out be dismantling the procedure and noting that y only appears in the parameter sequence.

For example,

dismantle(proc({y := 3 }) 'procname'('y' = 2) end proc);
PROC(10)
   EXPSEQ(2)
      ASSIGN(3)
         NAME(4): y
         INTPOS(2): 3
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   FUNCTION(3)
      PARAM(2): [-2]
      EXPSEQ(2)
         EQUATION(3)
            UNEVAL(2)
               PARAM(2): [1] <- this is the local y
            INTPOS(2): 2
   EXPSEQ(1)
   EXPSEQ(1)
   EXPSEQ(1)
   BINARY(2)
      0

Any idea where the errata is?  Web searches make mention of it, but I found nothing useful. It's not on the authors' sites.

The old lists get garbage collected, so the technique does not necessarily continually "erode memory".  However, it does require more memory activity (copying the list) and the increased frequency of garbage collection slows things down.  Not a good technique.

While that post is useful in its own right, it does not give an example of efficient list creation.  Rather it describes, purposely, an inefficient method for finding a minimum in a list that incidentally creates a list.  The suggested technique avoids list creation.

I realized why mine is different; it's not linux 64 specific.  My version enables a feature (some minor syntactic sugar) that isn't quite ready for public release.