Nice.  In hindsight the ansatz technique is straightforward, but I didn't think of it. 

Nice.  In hindsight the ansatz technique is straightforward, but I didn't think of it. 

Yes, I realized that after I has posted it.  Is there a reasonable way to compute the closed form from the iteration?  It's easy enough to see that iterants have the form

 x^3/2 + x*sum(Ai*ln(2)^i, i=1..n)

If you know that the coefficient of x is a rational polynomial (here bilinear form) in ln(2), then it is easy to compute it:

tmp := (A*ln(2)+B)/(C*ln(2)+D):
ident := coeff(psi(x^3/2+tmp*x),x) = tmp:
sol := solve(identity(ident, x)):
simplify(eval(tmp, sol));
                                    -7 + 12 ln(2)
                              -1/12 -------------
                                     2 ln(2) - 5

Yes, I realized that after I has posted it.  Is there a reasonable way to compute the closed form from the iteration?  It's easy enough to see that iterants have the form

 x^3/2 + x*sum(Ai*ln(2)^i, i=1..n)

If you know that the coefficient of x is a rational polynomial (here bilinear form) in ln(2), then it is easy to compute it:

tmp := (A*ln(2)+B)/(C*ln(2)+D):
ident := coeff(psi(x^3/2+tmp*x),x) = tmp:
sol := solve(identity(ident, x)):
simplify(eval(tmp, sol));
                                    -7 + 12 ln(2)
                              -1/12 -------------
                                     2 ln(2) - 5

What do you mean by randomly?  Hard to predict? With setsort, the behavior appears determininistic and I can correctly predict the outcome for simple cases (simple being defined as those I can successfully predict 8-).

Try debugging the procedure. 

debug(AffineMatEncode):

Then call the procedure. That should show you what is going wrong.  Did you eliminate the evalm calls?

You can use IntegerDeterminant from the LinearAlgebra[Modular] package, it should be more efficient.

Try debugging the procedure. 

debug(AffineMatEncode):

Then call the procedure. That should show you what is going wrong.  Did you eliminate the evalm calls?

You can use IntegerDeterminant from the LinearAlgebra[Modular] package, it should be more efficient.

While this won't always work, what I did was simple enough.  I ran the Maple XMLTools:-ParseFile command on the offending worksheet.  It returned an error message indicating that a Text-field element was not terminated.  I then opened the file in an editor and searched for that element.  Fortunately the Text field element that had the problem was the first one in the sheet.  I manually fixed it, saved the file, then reran ParseFile. There were a few other elements (Font and Task) that were improperly terminated.  I patched them, them opened the file in Maple and all was well. 

While this won't always work, what I did was simple enough.  I ran the Maple XMLTools:-ParseFile command on the offending worksheet.  It returned an error message indicating that a Text-field element was not terminated.  I then opened the file in an editor and searched for that element.  Fortunately the Text field element that had the problem was the first one in the sheet.  I manually fixed it, saved the file, then reran ParseFile. There were a few other elements (Font and Task) that were improperly terminated.  I patched them, them opened the file in Maple and all was well. 

I meant, is there a reason for its use as a sequence generator?  Maybe Iota was the Greek goddess of enumeration 8-? Possibly the correspondence between the standard use of i as incremental variable and iota is not coincidental.

Hmm.  Did that command name come straight from APL?  Is there any rational reason for it, other than that? It's one I'm not likely to remember...

FYI, a nicer way to generate basesymbols is

basesymbols := Array(0..35, map(seq,["0".."9", "A".."Z"])):

basesymbols := cat(seq("0".."9"),seq("A".."Z"));

The procedure cat also handes sequences, though the help page is not explicit about the use of character ranges. It forms the cartesian product, so you do not save anything (i.e. you need three calls to cat). 

basesymbols := cat(cat("", "0".."9"), cat("", "A".."Z"));

Happy Pi day

Why do you want to change the background color?  The reason I ask is that for many years, I wanted to do exactly that.  My motivation was that the bright white background hurt my eyes.  Since I switched to an LCD screen it has been less of an issue.  I still prefer a light gray background, but can live with the white.  It is possible to change the background color of the classic worksheet editor.

Why do you want to change the background color?  The reason I ask is that for many years, I wanted to do exactly that.  My motivation was that the bright white background hurt my eyes.  Since I switched to an LCD screen it has been less of an issue.  I still prefer a light gray background, but can live with the white.  It is possible to change the background color of the classic worksheet editor.

By normal Maple instructions I believe you mean, among other things, the use of the assignment operator (:=).   That cannot be done because the Maple assignment operator is not a first-order expression (with luck I'm using that term correctly).  That is, one cannot pass an expression with an assignment operator around as would be necessary to pass it to dsolve.   Maple assignments are statements that are executed.  The usual way to get around that is to pass a procedure that does the assignment to dsolve.  There are performance reasons that that is not supported.  The event handling is done in compiled code and requiring it to handle callbacks to Maple library code would be expensive.  

It may be possible to extend dsolve's event loop to handle compilable Maple procedures in the actions, however, that would not allow a table structure, though it would allow an rtable structure.  Consequently you'd only be able to save so many points---upto the allocated size of the rtable.

The help page could be better.  I'll submit a change request for an example using discrete variables.