In a 2014 thread BOINC vs PRPNet, it was stated:

Primorial and Factorial use PFGW which isn't (currently) supported on BOINC, although we could add the support if we wanted to.

So my question is, is this still the case today?

Would it be straightforward to add support for PFGW in BOINC?

It is my impression that results/residues from factorial and primorial tests on PRPNet are kept and shall be used for doublechecking when/if these subprojects move to BOINC.

I think the factorial and primorial searches would become much more popular if they were moved to BOINC.

/JeppeSN

Doublechecks don't need BOINC, although BOINC automates the process.
Sieving further is certainly doable.
A better question is why to port 'orial's to BOINC?
Would do more work on BOINC, but at the cost of existing sub-projects.

I think the factorial and primorial searches would become much more popular if they were moved to BOINC.

In a 2014 thread BOINC vs PRPNet, it was stated:

Primorial and Factorial use PFGW which isn't (currently) supported on BOINC, although we could add the support if we wanted to.

So my question is, is this still the case today?

Would it be straightforward to add support for PFGW in BOINC?

It is my impression that results/residues from factorial and primorial tests on PRPNet are kept and shall be used for doublechecking when/if these subprojects move to BOINC.

I think the factorial and primorial searches would become much more popular if they were moved to BOINC.

/JeppeSN

Jim may correct me if I'm remembering this incorrectly, but there's several non-trivial steps that need to be done.

1) PFGW on BOINC.

I'm sure we'll find some unexpected roadblocks getting that to work, but I'm also confident we'd eventually get it working.

But that success would lead to the second problem:

2) On BOINC, we'd use up the existing sieve files pretty quickly.

We'd have to open up sieving again and sieve to much higher n's this time.

And that takes us to the third problem: (This is where my memory is not as clear.)

3) At least one of the sieves can't go much higher.

So, yes, it's doable. But one of the two projects will quickly come to a close on BOINC not too long after it starts.

EDIT: I neglected to answer your question about double checking. Yes, we have residues, and I suspect we'd probably double-check all the PRPNet work.

In a 2014 thread BOINC vs PRPNet, it was stated:

Primorial and Factorial use PFGW which isn't (currently) supported on BOINC, although we could add the support if we wanted to.

So my question is, is this still the case today?

Would it be straightforward to add support for PFGW in BOINC?

It is my impression that results/residues from factorial and primorial tests on PRPNet are kept and shall be used for doublechecking when/if these subprojects move to BOINC.

I think the factorial and primorial searches would become much more popular if they were moved to BOINC.

/JeppeSN

Jim may correct me if I'm remembering this incorrectly, but there's several non-trivial steps that need to be done.

1) PFGW on BOINC.

I'm sure we'll find some unexpected roadblocks getting that to work, but I'm also confident we'd eventually get it working.

But that success would lead to the second problem:

2) On BOINC, we'd use up the existing sieve files pretty quickly.

We'd have to open up sieving again and sieve to much higher n's this time.

And that takes us to the third problem: (This is where my memory is not as clear.)

3) At least one of the sieves can't go much higher.

So, yes, it's doable. But one of the two projects will quickly come to a close on BOINC not too long after it starts.

EDIT: I neglected to answer your question about double checking. Yes, we have residues, and I suspect we'd probably double-check all the PRPNet work.

Question #1, how would pfgw need to change to support BOINC?

Question #2, how far has the sieving gone? mfsieve (part of the mtsieve framework), which replaced fpsieve/fsieve/fsievecl, can sieve up to 2^62.

I can't answer #2.

I can't answer #2.

I would be very surprised if it reached the 2^62 limit. Factorial and primorial sieves are iterative, which means that one must know the result of the previous term before testing the next term. Because of this iterative nature, it takes far longer to sieve a range than non-iterative sieves like ppsieve and srsieve.

It is possible that the older version of fsieve/fsievecl/fpsieve had a limit of 2^52. mfsieve has a limit of 2^62.

but I do not think it is a good argument that people would prefer them over other subprojects.

but I do not think it is a good argument that people would prefer them over other subprojects.

For what it's worth, I think too many subprojects is not good. Many subprojects like SoB, Cul, WOO (actually, most of them) are slow enough as it is and adding more subprojects will slow down progress on each individual subproject even more.

In the end, the question is, is it more worthwile to have pushed the leading edge on 12 different types of primes or to have found 1 or 2 new largest primes (of their type).

PrpNet is a testing area for projects which does have (yet) significant attention or of lesser mathematical importance. It's not expected to have high participation for them. (btw a fact that you're not familiar with console and command line does not mean that everybody here is). Eventually, these projects may receive more attention, become Boinc-ready and will be adopted by PrimeGrid. It happened with SR5. Or they may be shut down, like we did with wwww project due to software problems.

Regarding PFGW support:

It's not difficult to support it. Our new wrapper is highly modular and can be expanded to support any new program in just a few hours of coding.

But... PFGW have a problem with checkpoints. To be exact, it checkpoints only PRP tests. So all primorial/factorial tests must be run in PRP mode, and, if a PRP is reported, another test must be run on server to confirm that PRP is really a prime. It's not a problem again, we do this for GFN. But...

If we're going to run PRP tests anyway, is it possible to add such kind of PRP test to LLR2? Can this test use LLR2 features such Gerbicz check and fast verification? I don't know answers to these questions. But if it can be done, this approach will be much more efficient then using PFGW.

It's... more complicated. Jim and l seriously considered this not too long ago.

This is a case where we could end up with "too much of a good thing."

If we move Primorial and Factorial to BOINC, then we'll be running many, many more tests of Primorial and Factorial. That's a good thing, right?

It is, except that we'll exhaust the existing Primorial and Factorial sieve files very quickly.

Ok, so we just do more sieving.

Except that there's built in limits as to how high the sieve programs can sieve. We will hit those limits fairly quickly.

Unless we build a sieve program that can sieve much higher, if we move Factorial and Primorial to BOINC, they will be very short lived projects. Short enough that it's not worth doing.

Note that every time we've moved something from PRPNet to BOINC, the first step is always to do more sieving. This is no different. What's different this time is that it's not obvious how we can do enough sieving.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1