While Python is fully going for Dorabella cipher, 2/4 core i5 with 2,600 Ghz temperatures may look like this:

Thus, 70C/165F and 60-80% CPU should absolutely be normal. Both normally has no effect on the results.

QT

Quick: We are talking about "temperature" for simulated annealing.

Jarlve: Feel free to designate the variables, except that I would like more sub its, and then start the attack. I got best at 1,400,000, but maybe we could save some time and get similar results with 1,250,000. I think that has a much bigger impact than changing the temperature. Start the attack. I will download the new version in a day or so.

While higher substitution iterations will increase the solve rate, it may not be better in the same time frame, given that every substitution iterations costs time.

From your tests:

Substitution iterations * hill climber iterations * restarts / solves = substitution iterations per solve

200,000 * 10,000 * 500 / 12 = 83,333,333,333 substitution iterations per solve (83 billion)
400,000 * 10,000 * 500 / 51 = 39,215,686,274 substitution iterations per solve (39 billion) <— most optimal
600,000 * 10,000 * 500 / 70 = 42,857,142,857 substitution iterations per solve (42 billion)
800,000 * 10,000 * 500 / 80 = 50,000,000,000 substitution iterations per solve (50 billion)
1,000,000 * 10,000 * 500 / 94 = 53,191,489,361 substitution iterations per solve (53 billion)
1,200,000 * 10,000 * 500 / 110 = 54,545,454,545 substitution iterations per solve (54 billion)
1,400,000 * 10,000 * 500 / 130 = 53,846,153,846 substitution iterations per solve (53 billion) <— possible outlier (upwards)
1,600,000 * 10,000 * 500 / 115 = 69,565,217,391 substitution iterations per solve (69 billion) <— possible outlier (downwards)

– We could start with a base of 500,000 substitution iterations and slap on another 50,000 for every null & skip considered such that 12 nulls & skips would be tested with 1,100,000 substitution iterations.
– Similarly we could start with a base of 10,000 hill climber iterations and slap on another 2,500 per null & skip so that we end up with 40,000 hill climber iterations at 12 nulls & skips.
– From 10 nulls & skips use 6-grams.
– Temperature 40, shift 0-30%, div 2.

Interesting that 400,000 is optimal, but I understand. O.k., sounds good to me all of the above. I will post the above in the first post of this thread.

Interesting that 400,000 is optimal, but I understand. O.k., sounds good to me all of the above. I will post the above in the first post of this thread.

Great. I started a run in 2ND TRIALS: Z340, P15, RLTB and 8 nulls & skips. I’ve set the restarts (900) to a multiple of the nulls & skips divisions (9). So there are 100 restarts per division, more here is of course better but it is just a bit of a test to see if everything is still okay.

I am okay with this running until the end of the year and then starting from next year I want to do something else. Probably columnar rearrangement and keyed columnar transposition.

O.k., that sounds fine. I will continue to work on it with your program. Let’s see what happens with the attack. Maybe we will get a partial solve.

I grey shaded the cells that you aren’t working on to make it easier to visually find what division you are on, and will tidy up the spreadsheet a little to make it a bit more simple.

I have the new version running.

I have Nulls & skips set to 8, Manuals set to 0. My first restart was 8/0. But my second restart also is 8/0. The older version would have gone to 7/1 for the second restart, wouldn’t it have? Will the program go through the appropriate number of restarts at 8/0 before moving to 7/1?

Also, I noticed that you can see the current Shift % by looking at solver options. It changes throughout the iterations, as intended but you can see it. Just an observation.

I have Nulls & skips set to 8, Manuals set to 0. My first restart was 8/0. But my second restart also is 8/0. The older version would have gone to 7/1 for the second restart, wouldn’t it have? Will the program go through the appropriate number of restarts at 8/0 before moving to 7/1?

Never mind.

Hey smokie,

Here is a new AZdecrypt build with a faster solver while performance mode is enabled, about 10% for 5-grams, 20% for 6-grams and 30% for 7-grams. That should help us out quite a bit. As stated before, starting from 10 nulls & skips we should use 6-grams and I am working on a new set which will be ready soon.

https://drive.google.com/open?id=1kwlS7 … M-cy_5FIEB

O.k., sounds good. I will download and get started with it later today. Thanks!

Hey smokie,

Here is a new build, about 10% faster with performance mode enabled. The program files have 360_25 behind them, this means that the program/solver cannot run ciphers with more than 360 characters (including skips) and have no more than 25 repeats per symbol. For example the 340 has 24 "+" symbols so it just about fits in there. Doing it that way allows the program to run faster, that is why the limitation for this build, to finish our tests sooner.

https://drive.google.com/open?id=1HskBb … jPCfnVFWUY

I have just started with 6-grams. Use the ones that come with the full AZdecrypt download: 6-grams_english_jarlve_reddit.

o.k. that sounds good. I will download soon, am working on a division. If you get to the point where you need to pass me up with a null skip count, go ahead. But that probably won’t be for a few weeks.

Hey smokie,

I have calculated that going up to 12 nulls & skips will take another 5 months. That is a bit too long for me and want to shorten it to going up to 10 nulls & skips. That will take about 40 more days of our compute. Later on, higher nulls & skips counts can still be added to the test whenever anyone of us feels like or when we acquire more processing power.

You have done a great deal of work on the nulls & skips implementation in AZdecrypt and wonder if you want to be credited in some way. It’s a great solver and I am very happy about its performance. One unintended use of the nulls & skips solver is that it can run in period 1, effectively attempting to repair all sorts of defects. I would like to test it on daikon’s low level nomenclator ciphers. And considering renaming it to substitution + defects and add support for polyalphabetism via a toggle such that every position could be either a null, skip or polyphone.