Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

Advice Wanted for Sudoku Analyzer (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: Cross-fade using RB2005r3 3D features?
Next thread: Re: realbasic-games Digest, Vol 20, Issue 8


Re: realbasic-games Digest, Vol 20, Issue 8   -   Lars Jensen
  Advice Wanted for Sudoku Analyzer   -   Barry Traver
   Re: Advice Wanted for Sudoku Analyzer   -   Daniel Lurie
    Re: Advice Wanted for Sudoku Analyzer   -   Barry Traver
     Re: Advice Wanted for Sudoku Analyzer   -   Brian Rathbone
    Re: Advice Wanted for Sudoku Analyzer   -   Lars Jensen
     Re: Advice Wanted for Sudoku Analyzer   -   Barry Traver
      Re: Advice Wanted for Sudoku Analyzer   -   Barry Traver

Advice Wanted for Sudoku Analyzer
Date: 20.11.05 06:56 (Sun, 20 Nov 2005 00:56:46 -0500)
From: Barry Traver
I'm working on a simple program to do basic analysis of Sudoku puzzles,
which requires a 9 x 9 grid in which you can put single-digit numbers
from 1 to 9.

The coding, even though I expect it may be a bit complex, I think will
be the easy part. What I'm having trouble doing is creating the user
interface.

Since the user has to be able to edit the content of each of the boxes,
I've assumed (but I may be wrong) that the easiest way to approach it
would be to use 81 EditFields in a control array.

Two problems: (1) it is rather tedious to put the controls on the
window one at a time, but (2) when I try to clone several (e.g., 10)
controls at once (e.g., ten), sometimes it works and sometimes RB 2005
crashes <sigh>.

Any advice?

Barry Traver

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 20.11.05 13:07 (Sun, 20 Nov 2005 07:07:04 -0500)
From: Daniel Lurie
Barry Traver wrote:
> I'm working on a simple program to do basic analysis of Sudoku
> puzzles, which requires a 9 x 9 grid in which you can put single-digit
> numbers from 1 to 9.
>
> The coding, even though I expect it may be a bit complex, I think will
> be the easy part. What I'm having trouble doing is creating the user
> interface.
>
> Since the user has to be able to edit the content of each of the
> boxes, I've assumed (but I may be wrong) that the easiest way to
> approach it would be to use 81 EditFields in a control array.
>
> Two problems: (1) it is rather tedious to put the controls on the
> window one at a time, but (2) when I try to clone several (e.g., 10)
> controls at once (e.g., ten), sometimes it works and sometimes RB
> 2005 crashes <sigh>.
>
> Any advice?
>
> Barry Traver
You could use a control array, but I think the easiest option is to
"cheat" and use a canvas.
Use the keydown event to read the number they input.

81 editfields is a path leading to madness.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 20.11.05 14:12 (Sun, 20 Nov 2005 08:12:25 -0500)
From: Barry Traver
Daniel,

> You could use a control array, but I think the easiest option is to
> "cheat" and use a canvas.
> Use the keydown event to read the number they input.

Sounds like a great idea! Believe it or not, I've never worked with a
canvas before. Let me think out loud for a moment.

I want someone to be able to click on a square and then type the number
he wants in that particular square. Since I can get the location of the
mouse-click, I can have the program calculate the coordinates of that
square accordingly and then use the information from the number he or
she types in order to know what number to print at that location. (When
someone mouse-clicks at a certain location, I could even have the
outline of the square "blink" - using a timer control - so that the user
will have a visual clue as to where the number will be placed.)

I have a question, however. Whatever gets printed, I assume, stays
printed unless erased. If there is already a "5" at a particular
location and I then print an "8" at that location, the result, I think,
would be an "8" printed on top of the "5" already there, making a mess,
right? (After all, it's a piece of the canvas, not an EditField.) What
would be a good way to _erase_ whatever number may already be written in
a square at a particular location?

Barry Traver

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 20.11.05 20:28 (Sun, 20 Nov 2005 14:28:55 -0500)
From: Brian Rathbone
> I have a question, however. Whatever gets printed, I assume, stays
> printed unless erased. If there is already a "5" at a particular
> location and I then print an "8" at that location, the result, I think,
> would be an "8" printed on top of the "5" already there, making a mess,
> right? (After all, it's a piece of the canvas, not an EditField.) What
> would be a good way to _erase_ whatever number may already be written in
> a square at a particular location?

I think you will want to have a background image or some algorithm to
produce the playing board, and then draw the appropriate numbers,
perhaps from an array or dictionary during the paint event.

A good example of a game that does similar things is the Bejeweled
example that came with the exampleprojects download. Mars did a great
job of showing how to develop a canvas based game.

hth,

Brian
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 21.11.05 04:37 (Sun, 20 Nov 2005 19:37:58 -0800)
From: Lars Jensen
> Whatever gets printed, I assume, stays printed unless erased...
> What would be a good way to _erase_ whatever number may
> already be written in a square at a particular location?

You should code your Canvas.Paint event to draw over the entirety of
its Graphics parameter every time. Filling the entire Graphics
rectangle with white (using FillRect) is a common way to start a Paint
event. Or you could do FillRect for each square, if you happen to know
that they perfectly fill the Canvas (which I would imagine they do in
Sudoku, though you will have to pay attention to rounding effects at
the right and bottom edges of the Canvas).

It sounds like you might be laboring under the common misconception
that Canvas renders its image to some kind of persistent object that
is remembered and re-used as needed. That is not the case; whenever
part of your canvas needs to be drawn (as a result of opening the
window, resizing it, uncovering it, etc.), your Paint event will get
called, and there is no valid assumption it can make about what was
previously on that part of the screen. Each invocation of your Paint
event must stand alone.

Now, you might say "But Lars, that will be inefficient if only part of
the Canvas needs to be drawn!" And you would be right. But machines
are fast nowadays; you'll probably never notice a delay -- and if you
do, we'll help you get rid of it.

(BTW, I'm not sure what you mean by "basic" Sudoku analysis, but from
what little I've read, you might find that the UI is the easy part
after all...not that that should stop you!)

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 21.11.05 07:01 (Mon, 21 Nov 2005 01:01:52 -0500)
From: Barry Traver
Lars Jensen wrote:

>(BTW, I'm not sure what you mean by "basic" Sudoku analysis, but from
>what little I've read, you might find that the UI is the easy part
>after all...not that that should stop you!)
>
I'm accustomed to doing mathematical analysis of game positions.
Examples: my "Giant and Dwarfs" game (published in 99'er Home Computer
Magazine decades ago), my "Jump-a-Peg" puzzle program (published in
MICROpendium also decades ago), my "NimRow" game (adapted from one of my
- mostly mathematical - "Coney Games" collection I released decades
ago), etc., etc. (I did port over to REALbasic "NimRow," "31 or Die!",
and "Tic Tac Toe Philadelphia Style," which is now a magic trick in
addition to being a card game.) Like the card trick program, many of
these were inspired by Martin Gardner, especially by the "Mathematical
Games" column he wrote for years for the magazine Scientific American.

Also, when I was working on my B.A. in mathematics, I was invited to
become a member of Kappa Mu Epsilon, a national mathematics honorary
society, and I have taught math on the college (well, on the junior
college) level. I currently do tutoring in math, particularly preparing
high school students for the PSAT and SAT exams. And any math involved
in Sudoku is mostly just involved with expressing with numbers the
locations of the various squares (figuring out what row, what column,
and what block of nine, pretty simple stuff).

Fast description of Sudoku for those who may not yet have gotten caught
up in the craze. Picture a grid that is 9 x 9 in dimensions, making up
a total of 81 squares. In addition picture the 81 squares as being
broken up into nine 3 x 3 squares. The object is to fill in numbers (a
single digit in each square) so that these three things are true:

(1) each row of 9 contains all of the numbers from 1 to 9.
(2) each column of 9 contains all of the numbers from 1 to 9
(3) each 3 x 3 block contains all of the numbers from 1 to 9

What makes it a fun puzzle is that someone else has already filled in
some of the numbers, and you logically have to figure out what numbers
to put into the empty boxes.

Specific (very easy) example: picture a particular empty square.
Imagine that other squares in the same row already contain the numbers
2, 7, and 9. Imagine that other squares in the same column contain the
numbers 3, 8, and 7. Finally, imagine that other squares in the same 3
x 3 block contain the numbers, 5, 1, and 6. From that information, it
can be inferred that the only number that can be put in that square is 4
(since it can't be 1, 2, 3, 5, 6, 7, 8, or 9).

That's the sort of processing or "thinking" that a computer is very good
at. Now, most of the time, of course, it will not be as simple as my
example, but at least it should be easy to write a program that can
figure out the easier Sudoku puzzles. (And, besides, I'm mainly writing
it as an exercise, to make learning how to do graphics less painful
<grin>.)

What if you can't reduce the possibilities for a particular empty square
down to one? Well, then there are two possibilities: you have to hope
that in the process of solving other empty squares, you'll get enough
information to figure out this one, or you'll have to have the program
figure out the outcomes if you try each of two or more possible options
for that square.

The argument goes something like this: The number for such-and-such an
empty square must be a 4 or a 5. Let's assume that it's a 5. But that
leads to impossibilities elsewhere in the puzzle. Therefore the missing
number must be a 4. Simple mathematical logic!

So I don't expect a problem with the math or the logic, but the graphics
is a different story, since I've never done anything with a canvas
before (at least while understanding what I was doing).

Warm regards,

Barry

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Advice Wanted for Sudoku Analyzer
Date: 21.11.05 15:40 (Mon, 21 Nov 2005 09:40:54 -0500)
From: Barry Traver
Lars,

Barry Traver wrote:

> I'm accustomed to doing mathematical analysis of game positions.
> Examples: my "Giant and Dwarfs" game (published in 99'er Home
> Computer Magazine decades ago), my "Jump-a-Peg" puzzle program
> (published in MICROpendium also decades ago), my "NimRow" game
> (adapted from one of my - mostly mathematical - "Coney Games"
> collection I released decades ago), etc., etc. (I did port over to
> REALbasic "NimRow," "31 or Die!", and "Tic Tac Toe Philadelphia
> Style," which is now a magic trick in addition to being a card game.)
> Like the card trick program, many of these were inspired by Martin
> Gardner, especially by the "Mathematical Games" column he wrote for
> years for the magazine Scientific American.

What I meant to say was not "in addition to being a card game" (which it
isn't, although there is a card trick related to Tic Tac Toe in Martin
Gardner's book Mathematics, Magic, and Mystery) but "in addition to
being a con game."

All of my "Coney Games" are "con games," i.e., simple to learn and
seemingly more than fair to the con man's victim,, but actually much
favoring the con man (i.e., in the modern situation, favoring the
computer against a human opponent, so that often the human has _no_
chance of winning) (In Elizabethan English, the word "cony" meant
"rabbit," i.e., the con man's victim. A fascinating popular book of the
time on the forerunners to the more modern "shell game" is titled The
Cony-Catcher.)

Barry Traver

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>