New srbsieve and related programs testing/fixes

[rogue]

Originally Posted by gd_barnes

Were you able to run it and make it crash on an even Sierpinski base like Storm and I did?

OK Email me a link to your latest version of srsieve2 and I'll test it late tonight.

Any ideas for algebraic factorizations? I think you have them all in there. I'm not asking you to add any more. In the past I've tested all the way up to k's that are a 13th power and bases that are an 11th power and they looked good. Clearly I didn't consider testing forms where both k and b have a power but are different powers. (I remember testing them where both have equal powers to make sure the form had all of its n's removed.)

Are you talking about ideas for testing? There were quite a few specific forms in the post where I pointed out the original error. All appear to be fixed now. I would need to add more where the powers of k and base are the same, where only the k is a power, and where only the base is a power. Categories:
1. k and base a power and the same.
2. k and base a power and different.
3. k only a power.
4. base only a power.
5. Verify all work correctly for powers >=2 on Riesel and >= 3 on Sierpinski.
6. Aurifeuillean factors on Sierpinski bases.
7. Make sure recent changes haven't impacted anything else like forms with no powers for k or b or forms with a different character of powers. (Latter happened with recent fix.)

The last one is especially important. For instance, when you made the recent fix, it created a minor problem somewhere else. Fortunately that problem was very minor compared to the original one but oftentimes it is just as big.

It did crash with the previous version. The fix for mink=1 seems to have fixed it as it doesn't crash now.

The algebraic factorization code is messy and I would like to clean it up a little.

[gd_barnes]

Originally Posted by rogue

It did crash with the previous version. The fix for mink=1 seems to have fixed it as it doesn't crash now.

The algebraic factorization code is messy and I would like to clean it up a little.

I see. Let's not get too deep into cleaning it up right now other than to fix the current issue. After I'm comfortable everything is working well with srbsieve, then we can spend more time on cleanup. I'm with you there, though. Clean code is nice to have.

Regardless, I will still extensively test the current algebraic factor code to see if I can find any other issues. I'd definitely like to have more of a warm fuzzy about it so that I'm not constantly eyeing the algebraic-factor files that it writes out.

Would you like me to test the current public version or do you have a version that fixed the recent small problem? If the latter, Email it to me.

[storm5510]

Originally Posted by gd_barnes

Confirmation on the problem on even Sierpinski bases. You got the same output I did.

There still are 3 max parameters: maxk, maxNfbnsieve, and maxKrsieve2.

The Riesel is still running

maxk was the one which disappeared. I remember a slightly shorter number appearing above maxNfbnsieve.

Question:

Status (2023-06-08 13:23:47): Removed 101 terms from file for n = 6: 1483 remaining

From srbsieve in green text: Is this really terms or is it sequences? If it is sequences, then please change it. The two should not be interchangeable!

Edit: And here:

Status (2023-06-08 18:01:53):  Completed phase 2.  5237 k remaining

[gd_barnes]

Originally Posted by storm5510

The Riesel is still running

maxk was the one which disappeared. I remember a slightly shorter number appearing above maxNfbnsieve.

Question:



From srbsieve in green text: Is this really terms or is it sequences? If it is sequences, then please change it. The two should not be interchangeable!

Edit: And here:

Status (2023-06-08 18:01:53):  Completed phase 2.  5237 k remaining

maxk did not disappear. The program would not run without it.

sequences = terms = k's remaining when used in this context.

[storm5510]

Originally Posted by storm5510

maxk was the one which disappeared. I remember a slightly shorter number appearing above maxNfbnsieve.

It was maxfbncprimes. I found it in an older ini file that I saved. With all the changes, it may not be relative now.

[storm5510]

I ran hard into my RAM barrier earlier today. I had "maxNfbncsieve" set to 7. Parts of the screen turned gray and the widget said I had 0.1 GB RAM available. I thought I had solved this by increasing the size of the swap file. Obviously not. The swap file is 12 GB now. I could increase it to 16. What this really needs is a RAM upgrade. This system is five years old and I am unsure about investing anything more to put into it.

[gd_barnes]

Originally Posted by storm5510

I ran hard into my RAM barrier earlier today. I had "maxNfbncsieve" set to 7. Parts of the screen turned gray and the widget said I had 0.1 GB RAM available. I thought I had solved this by increasing the size of the swap file. Obviously not. The swap file is 12 GB now. I could increase it to 16. What this really needs is a RAM upgrade. This system is five years old and I am unsure about investing anything more to put into it.

I routinely set maxNfbncsieve to 10 with no problems. 16 GB RAM on a 2-3 year-old Windows machine.

I don't understand this swap file mess that you keep dealing with. All of my machines are stock out of the box, not custom designed at all. I rarely mess with them. All except one or two have 16 GB RAM. I just have to make sure they have the energy efficiency stuff turned off and they never go to sleep/hibernate and do a Windows update one/month.

You should get rid of the special swap file configurations and just let it use all of the RAM all of the time if needed. It would save you some headache.

[rogue]

maxNfbncsieve is dependent upon b. For base 3, you would set to value in the low 20s. For S586 I used 6. 7 would have caused fbncsieve to take longer than the first phase. I think that bases up to the max base on the project, for bases that are not started, would also use 6.

fbncsieve will sieve to sqrt(maxk*b^n). Consider how long that takes. That sieve depth increase quickly for higher bases.

[storm5510]

Originally Posted by gd_barnes

I routinely set maxNfbncsieve to 10 with no problems. 16 GB RAM on a 2-3 year-old Windows machine.

I don't understand this swap file mess that you keep dealing with. All of my machines are stock out of the box, not custom designed at all. I rarely mess with them. All except one or two have 16 GB RAM. I just have to make sure they have the energy efficiency stuff turned off and they never go to sleep/hibernate and do a Windows update one/month.

You should get rid of the special swap file configurations and just let it use all of the RAM all of the time if needed. It would save you some headache.

By default, a Windows 10 install will create a "system managed" swap file. In my case it is 2.3 GB. I suppose it bases this on the size of the drive it is installed on. I have a 250 GB NVMe.

I went into the advanced settings and changed mine from the fixed 16 GB to the system managed setting which required a restart. I set maxNfbncsieve to 7 and started srbsieve. I was looking for it to stall in the preliminary stages, but it didn't. The lowest I saw the RAM go was 5.6 GB in step 7. I take "system managed" size as meaning flexible. The OS may increase the size if it determines there is a need. There is no way I know of to see what it is doing on-the-fly.

My primary issue with higher settings for maxNfbncsieve is time. You wrote of what a person's patience tolerance is. 7 takes a couple of hours. 8 was going above 12 hours. This was beyond what I wanted to do. I don't know if using larger phase values will compensate for this or not. There is a point, in my experience, where the sequence removal count gets really low, < 5 for a phase > 5500. Sometimes zero.

When I built this system in 2018, the CPU was near top-of-the-line. Now, it is in the dust behind everything else which came along later. The dust is getting deeper. Functionally obsolete status comes in March of next year.

Below is the widget I have been referring to. It is at in idle state here.

[gd_barnes]

Originally Posted by storm5510

By default, a Windows 10 install will create a "system managed" swap file. In my case it is 2.3 GB. I suppose it bases this on the size of the drive it is installed on. I have a 250 GB NVMe.

I went into the advanced settings and changed mine from the fixed 16 GB to the system managed setting which required a restart. I set maxNfbncsieve to 7 and started srbsieve. I was looking for it to stall in the preliminary stages, but it didn't. The lowest I saw the RAM go was 5.6 GB in step 7. I take "system managed" size as meaning flexible. The OS may increase the size if it determines there is a need. There is no way I know of to see what it is doing on-the-fly.

My primary issue with higher settings for maxNfbncsieve is time. You wrote of what a person's patience tolerance is. 7 takes a couple of hours. 8 was going above 12 hours. This was beyond what I wanted to do. I don't know if using larger phase values will compensate for this or not. There is a point, in my experience, where the sequence removal count gets really low, < 5 for a phase > 5500. Sometimes zero.

When I built this system in 2018, the CPU was near top-of-the-line. Now, it is in the dust behind everything else which came along later. The dust is getting deeper. Functionally obsolete status comes in March of next year.

Below is the widget I have been referring to. It is at in idle state here.

Letting the system manage it is the way to go. I've never changed anything in Windows 10. It manages it well on its own.

Mark is right. maxNfbncsieve is dependent on base. When I quoted 10, I was doing a lot of running on bases < 100. I found 5 to be best for base 586. For base 1031, you might even want to go 4.

What's you want for maxNfbncsieve: Set it so that it will sieve all sequences where k*b^n-1 is <= ~13 digits. Above that srsieve2 will be faster.

Values to use for different bases:
Base 3: 10 to 25. Dependent on size of k.
Base 586: 5
Base 1031: 4 or 5

To calculate the size of a sequence, use:
n * log(base) + log(k) + 1

[storm5510]

Originally Posted by gd_barnes

Letting the system manage it is the way to go. I've never changed anything in Windows 10. It manages it well on its own.

Mark is right. maxNfbncsieve is dependent on base. When I quoted 10, I was doing a lot of running on bases < 100. I found 5 to be best for base 586. For base 1031, you might even want to go 4.

What's you want for maxNfbncsieve: Set it so that it will sieve all sequences where k*b^n-1 is <= ~13 digits. Above that srsieve2 will be faster.

Values to use for different bases:
Base 3: 10 to 25. Dependent on size of k.
Base 586: 5
Base 1031: 4 or 5

To calculate the size of a sequence, use:
n * log(base) + log(k) + 1

I decided to use R78 for a test. It easily handled maxNfbncsieve with a setting of 9.

maxfbncprimes must have a default if not specified. What is it? (Curious).

That memory allocation error I mentioned a while back. It came from a v7 alpha of srsieve2. I have not seen it again. My swap file tinkering was not necessary.

I have not done anything with R1031 for a while. After you pointed out others had done some things with it, I stopped. I looked at the pages you linked. The only thing I would know to do with it is to start it from scratch. I would have to figure out what the maxk needs to be. I used 6 for maxNfbncsieve and it did well.

I have been experimenting with phase increments. Some are linear as they rise. Others would make a curve if plotted, upwards and downwards. I know the limit is 100. That is way too many. I have kept mine below 20.

In a linear form, the removal of sequences drops considerably in the first few phases then begins to level as the phases continue to rise. This too creates a curve. My idea is to straighten the curve somewhat. Excel has been very helpful is devising tests. My thinking is to make the increments in the phases larger in lower values and decreasing the gap as they rise. All of this is a function of time required.

"n * log(base) + log(k) + 1." This throws me because it has both n and k in it.