My oldest son, Stuart, recently completed a Science Fair project on sudoku puzzles. While I am fairly good at solving sudoku puzzles, the mathematics is something that is completely outside my area of expertise. After seeing the paper by Hurzberg and Murty in the Notices of the AMS (June/July 2007) and additional papers by Felgenhauer and Jarvis (http://www.afjarvis.staff.shef.ac.uk/maths/felgenhauer_jarvis_spec1.pdf)  and Russell and Jarvis (http://www.afjarvis.staff.shef.ac.uk/maths/russell_jarvis_spec2.pdf) and Jarvis' sudoku webpage (http://www.afjarvis.staff.shef.ac.uk/sudoku/), I felt that I had a reasonable understanding of some of the basic ideas involved in counting unique sudoku puzzles. While I had nothing to add to the mathematical ideas, I did see the potential to create a tool to visualize these ideas. The result is the worksheet I just uploaded to MaplePrimes:

View 178_Sudoku3-20-03-08.mw on MapleNet or Download 178_Sudoku3-20-03-08.mw
View file details

I hope the instructions at the top of this worksheet are fairly self-explanatory. The coding is not always optimal. Remember that I wanted this to be something my son could understand. (Although, in the end, he never did get involved with any of the programming and did not use this tool in his presentations.) He ended up focusing more on the order-2 (4x4) sudokus. I found it very interesting that there are 576 4x4 Latin squares and exactly half of these produce valid sudoku puzzles. Even more surprising (to me) is that there are only 2 unique order-2 sudoku grids. I wrote a similar Maple worksheet for these puzzles, including a button that converts any 4x4 sudoku grid to one of the two unique grids. (It is not in a form suitable for distribution on MaplePrimes. If anyone is interested, I can share it.)

I welcome suggestions and enhancements that will make this a better tool for understanding sudoku puzzles. My worksheet does include a very rudimentary tool for solving a sudoku puzzle. This is something that could be easily improved by someone with the appropriate knowledge and time. If that is you, let me know and I will be happy to distribute an improved worksheet.

Enough about sudoku. Let's talk about embedded components and maplets

I have lot of experience writing maplets, and could see that as a natural way to implement the sudoku project. I also knew this would become pretty involved, with 81 textboxes for each puzzle, and getting the layout to look good could be difficult. So, I decided to give Maple's worksheet tables and embedded components a try. It was fairly easy to create the first 9x9 puzzle grid; the others were obtained by copy and paste. Letting Maple automatically name the different components was convenient - but this required extensive pre-planning as going back to add something earlier in the table could interfere with the regular numbering that would be needed to simplify the programming. Some user control over the automatic naming would be very empowering. Likewise, editing properties of a component can be done only through the GUI: (right click) Component Properties, edit, (OK), OK. To change the width of every cell in one puzzle grid requires more than 200 button clicks just to navigate through the windows. Many times I found it easier to start over. Another habit I have developed is to not put much Maple code in the actions inside a component. In general, I put only the code needed to call a procedure defined in an auto-executed (and hidden) section in the worksheet. I much prefer to edit Maple code within the regular GUI than embedded within a component. A separate source file might be even more advantageous, but I do not see how to do this and distribute the complete worksheet in a single download. (This brings to mind my blog entry on multipart MIME within Maple. I continue to believe this should be possible but have yet to find a way to really make it work efficiently.)

While layouts with tables and embedded components are easy to create, they do lack a lot of the functionality of maplets. For example, it is not possible to change the color of the background or foreground in an embedded compnonent. (If this was supported, it would allow me to combine the grid of TextAreas and the color-coded plot into a single grid. Similarly, it would be nice to be able to control the font used in a TextArea.

Maplets are much better at supporting this type of user-control. It is pretty easy to change the background and/or foreground of a TextBox or TextField or Button or almost any other maplet element. Still, there are some features of a maplet element that cannot be controlled (e.g., the contents of a Table element, as discussed on MaplePrimes recently).  And other features are needlessly complicated. For example, some elements are measured in terms of characters (TextBox, TextArea, Button) and others in terms of points (MathMLViewer). I understand this, up to the point where I am trying to design an attractive interface. The matter is made worse by the fact that the dimensions supplied are not always followed exactly. I would like the ability to tell Maple that some fields are fixed and others are flexible, and to use one set of dimensions to specify these sizes.

Lastly, there are several areas where maplets do not (yet?) allow certain reasonable elements or actions. While it is possible to have a multi-window maplet, control is always assigned to the most recent open window; the only way to pass control back to a parent (or to have sibling windows) is to close the child window. It would be nice to be able to insert a hyperlink in a maplet. This is easy to do with embedded components because you are already working in a worksheet. While images can be included in a maplet, the image has to reside in a predictable location (relative or absolute) on the computer running the Maple that controls the maplet. For more on this see my earlier blog entry on Maplets, Library Archives, and the Maplet Viewer.

I could write much more about how to nuance some quite nice effects from the existing Maplets package and some features that I believe it is missing. I believe it should not be difficult to extend the Maplets package to implement some of the features I have put on my wishlist. I have yet to dive deep enough into the coding of the Maplets package to have a feel for how it is implemented and how much work it would be to extend the functionality. Anyone with knowledge and/or interest in this area is encouraged to contact me.

Questions, comments, and other opinions are encouraged.

Doug

P.S. This was a nice post to earn my 500th point on MaplePrimes