| generic slither link app? |
tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2006.06.29 09:22:51
As of today, the process of getting my LoopDeLoop for mono build working on Mac OS-X is much easier, the required patches have been included in the main source code. Mono 1.1.16 (beta 2) will be released in the next few weeks, but if you can get the daily builds installed (I think installing 1.1.15 and then downloading the daily build 'recharge' and applying it over the top, should get the job done) you can try it even sooner. |
m2e
Kwon-Tom Obsessive
Puzzles: 607
Best Total: 16m 43s | Posted - 2006.06.29 10:19:57
I'll wait for the beta to come out, but greatly looking forward to your app! |
tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2006.07.08 06:16:52
Mono 1.1.16 is up on their website.
Here
Note that while (with a bit of luck) my mono version will run on the latest mono, it won't save settings as the mono people haven't added support for that yet. Also, the differences in available fonts between windows and mac will probably cause a host of graphical issues where labels are overlapping with textboxes etc, or labels are truncated. Once I actually have any mac users, I'll attempt to address these issues as they are raised. |
tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2006.08.05 00:37:17
Hrmm, PuzzleLover, do you think you could edit your post for me? - I am in the process of moving LoopDeLoop.exe and all my other downloads to www.themissingdocs.net
Currently they exist on both sites, but I'd like to take the files off of deadofnight.org at some time in the future, as that website is hosted on my little adsl connection where themissingdocs.net is hosted in the US on a much better connection.
New url for direct download is.
http://www.themissingdocs.net/downloads/LoopDeLoop.exe
http://www.deadofnight.org/Smiths_Stuff.shtml has been updated to point at themissingdocs and is the cannonical location for working out where to download form.
Last edited by tilps - 2006.08.06 23:44:11 |
RaDiCaLedward_26
Kwon-Tom Addict
Puzzles: 335
Best Total: 33m 17s | Posted - 2006.09.01 00:31:19
The LoopDeLoop app is not working for me. When I try to open it this message pops up:
LoopDeLoop.exe - Application Error The Application failed to initialize properly (0xc0000135). Click on OK to terminate the application.
Im not very good with computer problems. Could one of you tell me what the problem is? How can I get it to work? |
tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2006.09.05 01:55:31
Sounds like you don't have the .net 2.0 framework installed. If you follow the Smiths_Stuff link in my previous post you will find links to the .net 2.0 framework down the bottom of the page. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.04.11 04:18:44
Just a bump for this thread.
For the first time in a year I have done some work on Loop De Loop again.
Smith's Stuff
Direct download
The big feature is 'edge pair restrictions' which is logic based off of whether we know two edges can't be both filled, or both excluded. It isn't quite as powerful as edge coloring, but in combination with edge coloring alot of well known scenarios which were previously only solved via localized trial, are now solved without a trial at all.
Additionally if you have edge coloring and edge pair restrictions on, you can turn off cell/intersection interactions, as edge coloring and restrictions in combination are strictly a superset of the old cell/intersection interactions hack which I wrote.
There are also a couple of niceties in there now. You can cancel a puzzle generation part way through and get a puzzle to work on rather than nothing. (It will probably be easier than otherwise expected...)
Also when you click clear, and have autostart enabled, it will autostart again.
I still need to do advanced loop closing logic (hard), and my loop generation engine still performs really badly if you request a long loop on large puzzles (but I can fix that...). Also I had an idea for improving puzzle generation performance which I haven't worked on yet. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.04.11 14:29:02
So I did some more work, and a new release is out already. Beta 38 is a huge performance improvement over the release I did this morning. Generating beast size puzzles is now achievable in a reasonable time. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.11.20 13:45:05
Beta 40 is now up on my website. This version requires .Net 3.5, not just .Net 2.0.
Primary new feature is cell pairs. Enabling this allows the solver to consider how two adjacent cells interact with each other to produce useful outcomes as a basic operation. It works best in conjunction with edge coloring and edge restrictions. Since this is such a powerful option, I have made it so you can choose between having it enabled within trials, or only at the top level. Enabling at the top level lets you drop a level or two of lookahead distance while maintaining difficulty. Enabling it within trials is a cheaper alternative to enabling nested guess.
Additionally, if you truely do not like trials, you can now use a lookahead of -1 to disable them entirely.
Performance with the cell pair option enabled has not yet been optimized, so I hope to make it faster yet. |
Differ
Kwon-Tom Fan
Puzzles: 35 | Posted - 2009.11.21 08:09:08
Other than the restriction of no alternating colors around an intersection, what advantages does line/cross-based solving have over color solving? |
v_e_e_n_c_a
Kwon-Tom Obsessive
Puzzles: 2080
Best Total: 32m 53s | Posted - 2009.11.24 06:04:24
I tried your new version and it tooks about 6 minutes to generate beast (maybe I have slower processor than you) - I had setted look ahead to value -1 (as you said that this value didn't use lookaheads). But interesting is that sometimes it still uses lookaheads (as I can see with visual solver enabled)
But I wanted to tell you about small bug I found (months ago, but is still there). If you allow obviously invalid moves, suppose eg. situation like this:
try to draw on the board this:
and then remove one of the edge from center -> fails with OutOfMemory. Maybe bug in checking for loop (you are looping around and around, ...) |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.11.24 21:29:08
Quote: Originally Posted by v_e_e_n_c_a I tried your new version and it tooks about 6 minutes to generate beast (maybe I have slower processor than you) - I had setted look ahead to value -1 (as you said that this value didn't use lookaheads). But interesting is that sometimes it still uses lookaheads (as I can see with visual solver enabled)
|
The solver does not respect your current settings, it just tries to solve it. The settings are used by the generator alone.
What I suspect you saw was it solved the puzzle, but then attempted some trials on empty areas to fill in crosses.
When the generator is set to no-lookahead, it skips the trials phase and goes straight to the 'complete if done' phase. The complete if done phase checks that all numbers and intersections have their targets satisfied, and that there is a single loop. If this is true it fills all remaining edges with crosses automatically.
I should probably change my normal solver to run a complete if done check in between the 'start' and 'trials' passes. That would solve those trials.
As to the other bug, thanks for the report, I'll look into it. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.11.25 01:42:55
Beta 42 is now up. It has some more performance improvements (nothing amazingly huge) and it fixes the unset edge bug. |
v_e_e_n_c_a
Kwon-Tom Obsessive
Puzzles: 2080
Best Total: 32m 53s | Posted - 2009.11.26 21:23:42
I looked at your program once again and realised that it uses so many memory during generating puzzle. So if I tried to generate very huge puzzle (without trials) - 100x100 it fails with OutOfMemory exception. I look at resource manager and if I tried to generate 30x40 it uses around 100 MB.. I tried the same with my program (also made in C#) and for 30x40 puzzle it uses only about 10MB and for 100x100 about 13MB.. I was surprised why do you use so much memory..
Last edited by v_e_e_n_c_a - 2009.11.26 21:49:33 |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.11.27 05:40:49
I have several arrays which are edge.Count x edge.Count rather than using dictionaries. Its a space/performance trade off. One which I originally made when 20x14 was considered a large puzzle.
I don't see a desire to go any higher than 40x30, so I am not overly concerned at the moment.
On the other hand, my program does generate a huge amount of garbage very rapidly as well. That I am more concerned about, since about 20% of cpu time generating puzzles is spent just creating new objects and arrays, which I rarely need for long.
Last edited by Tilps - 2009.11.27 05:43:12 |
v_e_e_n_c_a
Kwon-Tom Obsessive
Puzzles: 2080
Best Total: 32m 53s | Posted - 2009.11.27 08:23:15
All I need is O(|E|) memory, where E is the number of edges.. I tried also to write some deduction technique based on O(|E|^2), but as I wrote in my thread it doesn't bring anything new for my solver (only more & time memory needed).. But I allocate all memory I will need when the constructor of generator is called. From that time no memory allocations are called.. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.11.28 01:30:57
One of the major reasons my app is the way it is is because my trials use a breadth first approach, they discover changes, but do not apply them until current depth of discovered changes are all processed.
It is done this way so that the limitation on trial distance is more realistic, but it does result in exactly the same thing being discover a huge number of times. So I have to have lookup tables to see if the same thing has already been discovered and discard it, or performance suffers greatly. Those lookup tables are cells.Count x cells.Count for cell shading, edges.Count x edges.Count for edge coloring and edge restrictions.
I have considered changing to the normal depth first approach if the trial distance is unlimited, it would likely perform MUCH faster, but the level of code duplication which would be involved is horrendous.
The other reason my app is the way it is, is because my edge restrictions are stored in an 2 dimensional array, despite the fact that I never discover edge restriction relations more than a fixed number of edges away...
I generate a lot of garbage on the other hand because of trials. Since I have to support undo to go back to before the trial, every action performed has to go into an undo stack. Possibly I should have made my action objects structs, but it does make programming awkward at times. |
grotmar
Kwon-Tom Obsessive
Puzzles: 1441
Best Total: 18m 0s | Posted - 2009.12.10 22:01:09
Are you supposed to use Nested Guess together with the full generator?
I only seem to be able to make puzzles with multiple solutions with both features on. |
Tilps
Kwon-Tom Obsessive
Puzzles: 6720
Best Total: 18m 37s | Posted - 2009.12.10 23:13:42
Wait what?
You shouldn't get any puzzles with multiple solutions...
You may get puzzles which can't be solved without invoking the limitation that there is only a single loop. But that is different.
The full generator doesn't respect the nested guess option... I think... |
grotmar
Kwon-Tom Obsessive
Puzzles: 1441
Best Total: 18m 0s | Posted - 2009.12.11 21:53:26
Your newest edition seemed to have both the Nested Guess and the full generator as starting features.
Every time I have tried to use them both together the program gives a rating of multiple solutions. |
