-
Notifications
You must be signed in to change notification settings - Fork 0
/
DevLog.txt
114 lines (104 loc) · 7.06 KB
/
DevLog.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Feb 26 2016 ---------------------------
So, I lost the original copy of this project on my old thumb drive, but I've
been able to catch up easily with what I had before the loss. The window stays
open now, and the loading function uses the windows Choose file dialog now.
Today, I had a breakthrough with the use of an array to represent a block.
Turns out, if the block has axis X Y and Z in that order, to rotate the block
(that is, rotate the array so it represents a rotation) one simply has to
swap the order of two axis and change a sign overall (x y z -> -y x z) or
change the sign of two axis (-x -y z). Furthermore, a mirrored block is made
by swaping two axis WITHOUT a sign change (xyz -> yxz) or making a sign change
without an order swap (xyz -> -xyz). This ALSO means that Mirroring the block
twice in two different ways leads to a regular rotation (mirror swap + mirror
sign = rotate swap&sign).
Now I just need to find out how to integrate all this into a struct...
March 1 2016 ---------------------------
Developments are coming on schedule so far. I have begun puting together the
system for how the block works. I'm going to go on to working on the solver
itself now. I think the hardest part will be integrating the rotation of the
blocks. I suspect I can utilize pointers to direct the space reading imple-
mentation accross the array somehow.
March 4 --------------------------------
Things have gotton tricky REALLY quick. I have to find a way to simulate the
rotation of different blocks, and I have a inkiling of a solution, but...
it's not a simple one. I basically have a list of the 48 rotation possibilities
in a coded list that the program checks every time the block gets rotated.
here, it can set the rotated dimensions. I have it set up at the moment
where a negative axis is represented by a negative "prime" dimension.
(so x -z y would yeild widthPrime = width, heightPrime = -depth, and
depthPrime = height). The thing I'm trying to find out now is how to use
the altered space by puting the original space block into order. I'm pretty
stumped, so I'm going to sleep on it.
March 5 -------------------------------
BOOM! solution. (kind of). I have set it up where it literally runs through
all 48 possibilities and takes note of what each configuration entails for
the axis of the block. It then uses that axis configuration to copy from
the standard block into a copy using an altered order. Right now, it's SUPER
wordy. (I think the log will give an exact number, but It was CLEARLY past
300 lines of pure switch code.) Hard coding the other 47 configurations
will be hard, but it should be straitforward at least.
March 7 -------------------------------
Yeah, ok, I'm not going to code all that. I think I found an alternative
though (check the change logs). I'm trying to test to see if it's really
doing what I want now, though.
March 10 ------------------------------
Things are going slow due to other work that needs to get done for school,
but I finally got a good piece of time for working with the block rotation
tester. It was a succes in producing every rotation/mirror possibility,
but there was a bug in the way I had arranged the axis for the rotations
#16-31. I did a switch of each mirrored set with a regular set, but it
was easy to switch back. I just hope I changed the documentation correctly.
March 25 ------------------------------
Wow, missed a good chuck of time here! Good news, though, things are going
well! I have successfluly constructed a form of display and puzzle reading
implementation, though both are fairly rudimentary and in dire need of
improvement sometime in the future.
The other big thing that I have accopmlished is important to the purpose
of the project, if in a bit of a frustrating way. I have completed a solving
algorythm that can successfully find solutions. The only problem is that
with a 13 block puzzle, even 36 STRAIGT HOURS of computation wasn't enough
to get even one solution. I expect this is because my estimate would put a
start-to finish executon at 30 permutations a second into the range of 10
days of straight executon. That is obviously too long.
There is another algorythm that I have in mind, but it will be far more
complicated to implement. The key would be to draw focus from placing every
block to filling every space. In this way, permutations can "spin" at shalower
situations (such as 2 or 3 blocks) rather than spining at 7 or 8 when it's
obvious that a solution doesn't exist because of block 3. In this way, false
permutations can get logically "Chopped" in larger chunks. One disadvantage
of the second solving algorythm is that it will be forced to operate on the
assumption that each space must be filled. Although it is a common assumption
for these kind of puzzles, it's still a limitation.
April 1 -------------------------------
I have success! Mostly, at least. The use of a space consideration in the
algorythm has been tremendously powerful! I abandoned the idea of having
the algorythm run entirely on a space-oriented basis; it was too difficult
to find a place where the solver could pause long enough for the status
to be drawn to the screen. Instead, I have merged the two notions. What
results is that the solver still permutates every block in every position
in every rotation one after another, but now it will check in-between each
block placement and check that each open space on the board still has at least
one block that can fill it without conflict. If this check fails, it will
continue with the algorythm as if the last placed block colided with a
filled space.
The effect on the algorythm efficiency is TREMENDOUS!!! Before, the algorythm
ran for 36 hours at about 30 permutations a second and found zero solutions.
The new algorythim running on the same computer was able to find more than 30
solutions! In a simmilar way, running at 1000 permutations per second, the first
algorythm ran fruitless for 4 hours while the second one foud 220 solutions!
To my dismay, however, there is a bug that has arrisen. I need to keep the
first block from traveling off the board. Hopefuly it's not something that
will throw off my algorythm.
April 15 ------------------------------
Things Are really coming together in the program! I found the bug I mentioned
in my last entry, and now the program can write solutions in text form onto
a file where the puzzle and blocks are kept. The naming system might need some
adjustments that way multiple puzzles can share a directory without steping
on each-other's "file toes" while solveing. The project is getting to a point
where I feel I have filled all of my original aspirations for completion, but
there are all kinds of things that I think this can grow to be. Some are simpler
than others, like how I would like to make a kind of "Pause on Solution found"
checkbox. I also would like to make the algorythm a bit more dynamic, like
finding a way to search into empty-space simplification by multiple levels
("ok, that block can fill that space, but will that keep other spaces from
being filled if that's the only case?")