I am very impressed by the programs GazL and dogpatch uploaded. I find it very hard to comprehend; my knowledge of C/C++ is way too modest.

If anyone is still interested, I've updated the code attached to
my previous post.

It's mostly clean-up after the refactoring for multi-threading, with some style clean-up and a few comments thrown in. I'm content with the code now, so I'm going to tag 4.6 "final".

It's been a fun little spare-time project for the last few weeks, so. a big "Thanks" to igadoter and dogpatch for bringing the challenge to our attention, and also to those like Astrogeek and Pan, who offered advice along the way.

my god, that is something I wanted to continue with, but you were faster.

looks like something is wrong with the number of threads or at least I don't really understand it well.

from my side it is very well written.

Thankyou.


The amount of threads that it will use are limited by:
1) the hardcoded max in the program, which is 32.
2) the value specified by the user.
3) the amount of "jobs" (i.e. candidate pair seeds) the problem can be split into: you can see how many of these there are when -v is used (just above the line about number of threads).

If there are less jobs than the amount of threads specified it just starts that many threads rather than having others sit around with no work to do.

For example, the default 1-32 circle, can use at most 6 threads.

... which reminds me. One thing I realised the other day was that picking a seed value with the most candidates will potentially allow for an additional thread or two. I was going to do that but forgot. It's a small job, so I'll slap it in a 4.7, then finally, it will be "final".

update: done, and 4.7 uploaded.

Thank you for your kind words. Appropriate that you give GazL top billing.

Here's my latest, version 1.4. It contains very few changes over 1.32. Reinstates make for WordRing and PalabraRing, and i think addresses those few remaining compiler warnings.

WonderRing_1.4.patch.txt

Calling it 1.4 rather than 1.33, because i don't anticipate another version anytime soon. Since i don't have a multi-core computer, probably won't even try to implement GazL's pthread logic.

2 members found this post helpful.

I think these are duplicates.
I take it you're kidding.

"mirror" is likely a more accurate term than "duplicate" for these: the sequence is unique, but a reversal.

Solving the "mirrors problem" was what drove the 3.x branch of my program's development and laid the groundwork for the multi-threading support that followed -- which kind of suggested itself and was just a natural evolution. I wish I could claim to have planned it from the outset, but if I did, I'd be lying.

2 members found this post helpful.

Yes, in my program mirrors (duplicates) are always generated. If you run it with option -o (ordered) it will still internally generate the mirrors (unlike GazL's code), but will not display or count them.

No, i openly acknowledge GazL's code to be superior.

The challenge long ago met, and looks like the thread is gracefully wound down. Will mark it as [SOLVED]. Many thanks to all who participated.

I enjoyed this one too.
My thanks