From: Nungester, Bob Subject: New SOMA program Date: 11. november 1999 I used to play with a SOMA cube back in the 60's, and I wrote a program to solve figures back around 1982 on an Apple II. Recently, I decided to resurrect the program and add graphics to it. I just finished today so I decided to search the Web to see if there is any information out there regarding the SOMA cube. I found Thorleif's SOMA page and got a lot more information than I expected. I'm sure you'll be interested in this program. When I found the site today, I saw you already have a program to solve figures. If I'd known that I probably wouldn't have bothered to write mine, but it's done now anyway. With the Apple II it took hours to solve a figure. The new program takes a maximum of 0.11 seconds (with the display turned off, using a 400 MHz Pentium II) to solve any of the original puzzles. Try the program and see what you think. Just copy the three attached files to a temporary directory and then run the SETUP.EXE file. After installation you can delete the three files. The program was written and compiled in Visual Basic 6 on a Windows 98 machine, but it should run in Windows 95 also. My program uses a recursive subroutine to place each piece in order and then cycle through all the other pieces (a type of tree search) until a solution is found. It also has a routine to speed up processing, very similar to your parity checking routine, which locates each "island" of contiguous spaces to be filled and checks that the number of spaces is acceptable (I guess great minds think alike :-). This is also done with another recursive function. Since I was starting from scratch I made up my own file format (see the 40 .SOM files included with program). Each one is simply 27 X,Y,Z coordinates to be filled. Let me know what you think of the program. The program is freeware and you're welcome to distribute it and post in on your site, but just put my name down in the credits. From: Nungester, Bob Subject: SOMA Windows program Date: 17. november 1999 OK, I read about deploying VB6 projects and here's what I learned. The bad news is that any VB6 executable needs MSVBVM60.DLL, which is the HUGE 1,376K file. The good news is that not much else should be needed. According to an on-line Microsoft article, all of the other DLLs that are required to run any VB6 application should already be on the machine of any Windows user that can log onto the Internet. Therefore, the only others that are needed are the executable and any particular components that it references. There's only one component I used, and that's a Common Dialog Box control that presents standard file open and save (or Append To) screens. Here's the list of files that should theoretically represent a full install: SOMA.EXE (100K) The program itself SOMA.CFG (3K) A small text file I used to store all possible rotations of each piece MSVBVM60.DLL (1,376K) The big "Microsoft Visual Basic Virtual Machine 6.0" [insert majestic trumpet music here] file needed for any VB6 project (thanks Bill G.) COMDLG32.OCX (137K) The Active-X Common Dialog Box component, it's worth the 137K Thorleif, please try unzipping the four files in a directory and see if this works. I'm not sure it will since there was some problem with that initial .CAB package, but let's hope for the best. Hopefully, if there is a problem it will say which DLL it can't find. I'll also try installing this package on a friend's machine. Both of my machines already have all the DLLs so I can't tell if anything is missing from the package. Courtney should have no problem with the small ZIP file to simply update the two SOMA.xxx files. By the way, I completely abandoned the old .SOM figure files that my program originally used, so you can delete them off your computer. Once you get the program to start, try opening your NONONIMO file first. I was amazed that this works as well with a 1,069 figure file as it does with the standard 25 figure files! You guys will need to be the beta-testers for this program since my wife and other friends just don't seem to understand the importance of SOMA. Please let me know if you find any way to crash the program, or if you have any suggested improvements. With the new features there's so many combinations of events and program flow that there may be some way for a user to get into an area that's not appropriate at the time. For example, the setup grid is disabled during the processing of a solution, but I might have missed some other combination of events where a control should be enabled/disabled and it isn't. I haven't written any instructions for the program yet, but it should be fairly obvious since it's a Windows program anyway and you guys were the ones that wrote all the file format and thousands of figures. Thanks for your great SOMA sites and the amazing figures. Without that I would have stopped at the last version. Let me know what you think, and enjoy the program! From: Nungester, Bob Subject: SOMA Date: 17. november 1999 I added a check box to allow viewing the solutions as stored in the file, or with all red cubes. I also replaced the slider for selecting speed with a standard scroll bar, eliminating the need for a several hundred K DLL. Rather than doing another screen shot, I thought we should work on getting the program running on your machine! From: COURTNEY FARREN Subject: Windows Dsolve Date: 20. november 1999 Bob works fast. He just finished a prototype for a Windows double-set solver. Where does he get the time to do all of this? Anyway, I tested his Dsolver. He uses the same routines I did in way back when I wrote Dsolve 1. Below is an excerpt of a letter I wrote to him: ******************** (Bob wrote:) 1. Piece rotations (already implemented) - only unique rotations of each piece are used, as written into the SOMA.CFG file. (CMcF wrote:) ---- What does this mean? I'm thinking that pieces #1, 3 & 4 have 12 rotations; piece# 2 has 24, pieces #5 & 6 have 12 each and piece # 7 has 8. ~~~~~~~~~~ (Bob wrote:) 2. CountAdjacent() (already implemented) - the equivalent of ISLAND (CMcF wrote:) ----I also see that you start off with both #1 pieces, which means that the left-over islands MUST have a multiple of 4 cubes. I have an additional check here: I'll explain later in PARITY. ~~~~~~~~~~ 3. Piece Order - with two sets, as the second copy of any particular piece is moved through the figure, it is started just after the position of the first copy of the same piece. To place it anywhere before it's twin piece would be a duplicate of when it's twin was already there (sort of a "back to the future" type of thing). This reduces the possibilities of EACH PIECE by roughly 1/2 (1/2x1/2x1/2x1/2 ... = lots of reduction). ---- This is exactly what I do. Lets say there are 100 positions for a particular piece. If the 1st piece is at position #1, then the twin has to check positions 2-100. When the 1st piece is at position #2, then the twin only has to check positions #3-100, and so on and so on. So instead of 100^2 combinations, there are 99+98+97+96+...+1 = (99*100)/2 which is about (100^2)/2, or half as much. ~~~~~~~~~ 4. Parity Check - This will be more complicated with a double set, but that's what makes it fun. ----Do we have the same definition of parity? The reason I ask is because I've noticed the twin #1 pieces are violating the parity rule while solving a double figure. Here's what my program does: First it detemines the parity of the entire structure. A double-set figure can only have parities of -10, -8, -6, -4, -2, 0,+2, +4, +6, +8 and +10. If the parity is a multiple of 4, then the twin #1 pieces HAVE to compliment each other. In other words, if piece #1a has a parity of -1, then piece #1b has a parity of +1. If the parity of the entire figure is NOT a multiple of four, then the twins must have the same parity. Because my piece order is 1-7-3-4-5-6-2. I can get the parity pieces (1-7-3) out of the way first. After all the 1's, 7's and 3's are removed, the remaining structure MUST have a parity of ZERO (since pieces #4,5,6 & 2 have no parity). Not only that, but the remaining individual ISLANDS must also have zero-parity. ~~~~~~~~~~ >5. DoEvents - This is simple. DoEvents is the Windows call that simply >means "go off and see if the user clicked on anything". It has to be called >frequently or you get the feeling the machine locked up and isn't >responding. I've got it pretty low down in the loop on loop on loop ... >structure now. I can call it much less often without affecting response to >user inputs. I understand this. Mine does not have any. If it did, the solving process would be much slower. ~~~~~~~~~~ 6. Symmetry - This is one I don't know if I can implement. My method of moving pieces through the figure doesn't lend itself to figuring what can be eliminated because of symmetry, but I'll think about it and maybe come up with a way. There is a way to utilize symmetry, and I'll give a stab at explaining the concept: The double set figure is symmetrical. Piece #1 therefore has a "mirror-image position" for every "initial position". While piece #1A sits in the inital position, piece #1B will eventually reach the mirrored position. As the recursion continues, piece #1A will eventually reach the mirrored position, but it doesn't have to since there was no solution while it was at the initial position. If there was, the program would have stopped a long time ago with a solution. ~~~~~~~~~ And So It Continued ..........