Help with Sudoku solver conversion from C

[Snorlite]

Hi, I would like to implement in LabView this solveSudoku function written in C that makes use of recursion, but I can't manage to make it work.

The full project is in the attachment. The VI in which I have trouble is called solveSudoku.

Thanks for the help.

[RavensFan]

If you need help, then help us help you by telling us in what way your code is not working.

[altenbach]

Posting by phone, only looking at your picture: shouldn't the 2D array be in a shift register?

[Snorlite]

The program seems to continue to try to insert the number 1 in row 0 column 1, after having inserted it in row 0 column 0.

Yeah, maybe I should have set the shift registers, but the problem still persists.

[aputman]

Unfortunately I can't open the project. Are the pictures showing the SolveSudoku VI? If so, you don't want to init the matrix on every call of the solver.  That should be done in your main VI. 

[aputman]

A few other questions and quality-of-life comments...

Did you set the solver to be re-entrant?  If you don't, your shift register values are overwritten because you'll be calling the same instance of the VI.  You need a separate instance of SolveSudoku.vi each time it is called.

Why use an outer while loop when a for loop is easier to understand in the context?

There is a +1 primitive for incrementing a value by 1.

Inside the helper functions, create a gridOut terminal so that you hide those wire branches. 

[altenbach]

Why is the output matrix not wired to anything?

[aputman]

I also notice you have a flaw in your interpretation of the algorithm.  If an insert is not possible, you should not call the solver.  There needs to be a break there so you can advance to the next number.  

[Snorlite]

Yes, they are SolveSudoku VI screenshots.

Yes, I have set it to be re-entrant.

@altenbach if you're talking about the last screenshot, the output matrix wire is the one inside the case selector (It's just partially hidden by the selector border, sorry).

Btw, yeah, I found the logic problem too: I had to recursively call the VI only after a successful insertion.

Thanks for the tips.

[alexderjuengere]

@aputman wrote:

Unfortunately I can't open the project. Are the pictures showing the SolveSudoku VI? If so, you don't want to init the matrix on every call of the solver.  That should be done in your main VI. 

I downloaded Sudoku.zip ‏225 KB and I can run the main.vi -

after a few seconds it throws the error 0x5F9 - too many recursive calls, because of "solvesudoku.vi"

You do call solvesudoku.vi within solvesudoku.vi - I think there's an easier way to do,

what you are trying to achieve.

When I delete the instance of "solvesudoku.vi" within solvesudoku.vi, run the .vi, I get this:

 

When I use a Shift Register instead of the Tunnel, run the .vi, I get this:

(0_solveSudoku_MOD.vi does recursive-ly calculates the first row correctly, according to this source)

 

Think of Recursion in terms of Shift Registers, not in VI Calls !

edit: looks like you managed to do it with recursively calling the solvesudoku.vi -

would you show us your modification(s)?