golang/sudoku-funpark
golang/sudoku-funpark
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Improve workload calculation and splitting of tasks #27

New Issue
Closed
opened 2025-02-02 19:18:46 +01:00 by sacha · 1 comment
sacha commented 2025-02-02 19:18:46 +01:00
Owner
Copy Link

Current workload (and splitting of it) is based on the blanks in the first row of the Sudoku puzzle. While this is an easy and quick solution, this leaves with a number of issue:

  • There can be more agents than blanks, leaving same agents unable to help.
  • There are no blanks, meaning the workload can not be split up
  • There are more blanks than agents meaning one or more agents will get an extra workload
    In short, this simple implementation works fine, but introduces issues later down the line.

Another approach would be:

  • Pre-generate all the potential solutions as one workload
  • Split the workload equally
  • Have the agent run set workload.

The downsides of this approach are:

  • Rewrite how solutions are validated
  • Pre-generating all possible solutions may be a costly operation in itself

I will start a new branch to check if this can work, and what the benefits are.

Current workload (and splitting of it) is based on the blanks in the first row of the Sudoku puzzle. While this is an easy and quick solution, this leaves with a number of issue: - There can be more agents than blanks, leaving same agents unable to help. - There are no blanks, meaning the workload can not be split up - There are more blanks than agents meaning one or more agents will get an extra workload In short, this simple implementation works fine, but introduces issues later down the line. Another approach would be: - Pre-generate all the potential solutions as one workload - Split the workload equally - Have the agent run set workload. The downsides of this approach are: - Rewrite how solutions are validated - Pre-generating all possible solutions may be a costly operation in itself I will start a new branch to check if this can work, and what the benefits are.
sacha commented 2025-02-04 01:48:13 +01:00
Author
Owner
Copy Link

This failed horribly. My PC was frozen for hours and hours until the program got killed. This was on the long running test. On the short running test, predictions were wack and all over the place, and it took 1 minute instead of ~15ish seconds. This endeavor was a waste of time. Easy to implement, but ultimately a waste.

This failed horribly. My PC was frozen for hours and hours until the program got killed. This was on the long running test. On the short running test, predictions were wack and all over the place, and it took 1 minute instead of ~15ish seconds. This endeavor was a waste of time. Easy to implement, but ultimately a waste.
sacha closed this issue 2025-02-04 01:48:13 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
High Priority
Things I would like to get done first.
Hotfix
Fix breaking issues.
Low Priority
Things that are nice to have.
TODO
Things I would like to get done.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sacha
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: golang/sudoku-funpark#27
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?