I spent a few hours on pdffilter.f90 and some surrounding code. So far just from working to understand the bounds claimed in the codes comments
There are things that are not true:

1. - red(), lines 158-161. "The quotient is exact" isn’t true. x*qi is inexact. What is true is that rounding it to an integer gives the right integer

2. - reds(), lines 167-168. "quotient error (<= 2^-13)".

I get 2*2^-24*(2^19/257), about 2^-12.

For the values the code actually produces (|x| <= 2*((q-1)/2)^2, so |x|/q <= q/2) the error is <= 2^-14

3.
A question for Eric, I would like to know if coefficients this large is possible in general:
x^10 + 3475x^9 + 337500x^8 + 36x^2 + 125100x + 12150000

While playing with the code I found coefficients that large cause an overflow issue in the original polDiscTest_cpu.cpp . But I dont know what ranges are actually being tested

Eric, I'm assuming GPU will also have a fast app as I'm not seeing them when I ran the test recently.

I tested stock versus fast app (w/o boinc) on three DS16x10 tasks on my 5070 recently and I'm seeing a 24x, 25x and 27x speed improvement.

Just my opinion: It would be nice to have a bump in credit, perhaps a reasonable compromise (not too excessive and not downright poor) considering that we can now finish the existing current search over S={2,5} field much faster by at least 10X to reflect that software improvement.

I would also like to know if coefficients this large is possible:
x^10 + 3475x^9 + 337500x^8 + 36x^2 + 125100x + 12150000

While playing with the code I found coefficients that large cause an overflow issue in the original polDiscTest_cpu.cpp . But I dont know what ranges are actually being tested

When you say this causes overflow, what exactly do you mean? Is the polDiscTest failing on the polynomial? Did you concoct this polynomial or did it come out of the algorithmic search space?
Its discriminant is a square but It is reducible: (x+100)(x+3375)(x^8+36). The power of 2 in it's discriminant is way beyond anything possible for the imprimitive fields we search for. I would have to think about it, but I'm not sure if the search space can even generate such a polynomial.

The passiflora version does everything modulo q for small primes q, so it does not have an overflow problem. As you alluded to, it also does floating point and then rounds to the nearest integer.

Eric, I'm assuming GPU will also have a fast app as I'm not seeing them when I ran the test recently.

I tested stock versus fast app (w/o boinc) on three DS16x10 tasks on my 5070 recently and I'm seeing a 24x, 25x and 27x speed improvement.

Just my opinion: It would be nice to have a bump in credit, perhaps a reasonable compromise (not too excessive and not downright poor) considering that we can now finish the existing current search over S={2,5} field much faster by at least 10X to reflect that software improvement.

For some reason, no tasks were sent to linux GPUs. There may be a problem with the plan class, but I can't see anything offhand. Some tasks were sent to windows GPUs. The linux CPU version was a hog with the 1000 test cases that were originally put out - it has now been validated and deprecated, to give other apps a chance at testing.

When you say this causes overflow, what exactly do you mean? Is the polDiscTest failing on the polynomial? Did you concoct this polynomial or did it come out of the algorithmic search space?
Its discriminant is a square but It is reducible: (x+100)(x+3375)(x^8+36). The power of 2 in it's discriminant is way beyond anything possible for the imprimitive fields we search for. I would have to think about it, but I'm not sure if the search space can even generate such a polynomial.

The passiflora version does everything modulo q for small primes q, so it does not have an overflow problem. As you alluded to, it also does floating point and then rounds to the nearest integer.

I concocted it to just work through the passiflora code.

What I mean by "overflow": the stock polDiscTest_cpu returns FALSE for the polynomial, even though its discriminant is square. The cause is an int64 overflow in the second unwrapped iteration (degR == 8 branch, line 203, R[k] = B[8]*R[k] - R[8]*B[k])

If you list the main problems, I can fix them. Claude science couldn't find a problem , maybe it's terrible at math like me.

---

If you list the main problems, I can fix them. Claude science couldn't find a problem , maybe it's terrible at math like me.

I already listed two. But I cant tell you how important they are or what should be done about them because I havent understood all of the code yet. But the possible issue I found in polDiscTest_cpu that I mentioned to Eric is more important for me to understand at the moment anyway because it may impact the assumptions in Passiflora

I can just as easily throw Claude at it because I myself use it in research but much more carefully, and in much smaller atomic steps, than a one-shot "please solve x".

I say this as someone experienced with this way of working: If we just throw Claude at the problem then whatever solution comes out could have other problems, it will take more time to solve, compared to gaining an understanding if the first solution even has guarantees at all

Many times I have told people what they are doing when trying to solve problems with LLMs like this is what I call the reverse chinese room argument.

Read up on the chinese room argument, and convince yourself that this is a mirror image of that.

I'm also an enterprise software engineer for systems that arent life threatening nor dealing with money. In that case we are much more cowboy because the consequences are low.

In science a solution means very little without understanding and correctness must be guaranteed, and LLMs are wrong a lot.

I highy recommend Prof Scarciotti's video: https://www.youtube.com/watch?v=KqiDqJMxg6o

When you say this causes overflow, what exactly do you mean? Is the polDiscTest failing on the polynomial? Did you concoct this polynomial or did it come out of the algorithmic search space?
Its discriminant is a square but It is reducible: (x+100)(x+3375)(x^8+36). The power of 2 in it's discriminant is way beyond anything possible for the imprimitive fields we search for. I would have to think about it, but I'm not sure if the search space can even generate such a polynomial.

The passiflora version does everything modulo q for small primes q, so it does not have an overflow problem. As you alluded to, it also does floating point and then rounds to the nearest integer.

I concocted it to just work through the passiflora code.

What I mean by "overflow": the stock polDiscTest_cpu returns FALSE for the polynomial, even though its discriminant is square. The cause is an int64 overflow in the second unwrapped iteration (degR == 8 branch, line 203, R[k] = B[8]*R[k] - R[8]*B[k])

Using the real search space, there is one I found that comes very close to the overflow. The overflow happens at bit 64 obviously, so 63 bits is max.

sf3_DS-16x271-1_Grp99 reaches 62 bits.

polBuf row: 1 0 0 5600 -102000 -2160400 -18605000 -172200000 809598750 11400000 40000

Not a square though but we know they get this large

Edit: I've found a few 63 bits too

When you say this causes overflow, what exactly do you mean? Is the polDiscTest failing on the polynomial? Did you concoct this polynomial or did it come out of the algorithmic search space?
Its discriminant is a square but It is reducible: (x+100)(x+3375)(x^8+36). The power of 2 in it's discriminant is way beyond anything possible for the imprimitive fields we search for. I would have to think about it, but I'm not sure if the search space can even generate such a polynomial.

The passiflora version does everything modulo q for small primes q, so it does not have an overflow problem. As you alluded to, it also does floating point and then rounds to the nearest integer.

I concocted it to just work through the passiflora code.

What I mean by "overflow": the stock polDiscTest_cpu returns FALSE for the polynomial, even though its discriminant is square. The cause is an int64 overflow in the second unwrapped iteration (degR == 8 branch, line 203, R[k] = B[8]*R[k] - R[8]*B[k])

It's not the size of the coefficients here that matter in regards to overflow - its how the coefficients combine to form the discriminant. When I last optimized the algorithm (years ago), given the bounds on the coefficients, I determined that the first iteration of the resultant calculation (used in computing its discriminant) would easily fit within 64 bits.

The algorithm bounds the size of the coefficients using symmetrical polynomials of its roots. Your constructed polynomial does not satisfy the coefficient bounds - if you form the square root of the sum of the squares of the roots, you get 3376. The constant coefficient must be bounded by this which it is not. Therefore, this polynomial would never have even reached the polDiscTest routine.

When you say this causes overflow, what exactly do you mean? Is the polDiscTest failing on the polynomial? Did you concoct this polynomial or did it come out of the algorithmic search space?
Its discriminant is a square but It is reducible: (x+100)(x+3375)(x^8+36). The power of 2 in it's discriminant is way beyond anything possible for the imprimitive fields we search for. I would have to think about it, but I'm not sure if the search space can even generate such a polynomial.

The passiflora version does everything modulo q for small primes q, so it does not have an overflow problem. As you alluded to, it also does floating point and then rounds to the nearest integer.

I concocted it to just work through the passiflora code.

What I mean by "overflow": the stock polDiscTest_cpu returns FALSE for the polynomial, even though its discriminant is square. The cause is an int64 overflow in the second unwrapped iteration (degR == 8 branch, line 203, R[k] = B[8]*R[k] - R[8]*B[k])

It's not the size of the coefficients here that matter in regards to overflow - its how the coefficients combine to form the discriminant. When I last optimized the algorithm (years ago), given the bounds on the coefficients, I determined that the first iteration of the resultant calculation (used in computing its discriminant) would easily fit within 64 bits.

The algorithm bounds the size of the coefficients using symmetrical polynomials of its roots. Your constructed polynomial does not satisfy the coefficient bounds - if you form the square root of the sum of the squares of the roots, you get 3376. The constant coefficient must be bounded by this which it is not. Therefore, this polynomial would never have even reached the polDiscTest routine.

Yes at a glance it looked like the magnitude of the coefficients would be proportional to how they combine, so thats why I worded it that way.
I'm going to move this to another thread tomorrow to ask you more about this

The algorithm bounds the size of the coefficients using symmetrical polynomials of its roots. Your constructed polynomial does not satisfy the coefficient bounds - if you form the square root of the sum of the squares of the roots, you get 3376. The constant coefficient must be bounded by this which it is not. Therefore, this polynomial would never have even reached the polDiscTest routine.

Actually, this was not quite right. The calculation needs to be done with the degree 5 relative polynomial, but you get the idea.

Just my opinion: It would be nice to have a bump in credit, perhaps a reasonable compromise (not too excessive and not downright poor) considering that we can now finish the existing current search over S={2,5} field much faster by at least 10X to reflect that software improvement.

Normally, that is what would happen.
But as there will be a new faster application that will be working on new Tasks that take longer to complete to keep the load on the servers down, and they will be running alongside the old application, it will complicate matters.



As i posted earlier

While the Optimised application Tasks should produce significantly more Credit per Task, as more work is actually being done, but if you are to keep the existing application to process Tasks then the new one will need to result in a similar amount of Credit per hour.
A task that requires 10 times the processing should get 10 times the Credit- but if it gets 10 times the Credit for a similar processing time to the existing Tasks and applications, then no-one will want to continue processing the current Tasks and applications- they'd need 10 times the Credit as well (even though they're doing 10 times less work).

The past has shown time and time again- if there isn't parity in Credit between applications, and the difference is more than just extremely minor and people can choose the higher paying work over the lower, then they will.
And in many cases, even if they can't easily choose- if they can identify the Tasks that will give more Credit, they will just abort those that don't.

---

Grant
Darwin NT, Australia.

For some reason, no tasks were sent to linux GPUs. There may be a problem with the plan class, but I can't see anything offhand. Some tasks were sent to windows GPUs. The linux CPU version was a hog with the 1000 test cases that were originally put out - it has now been validated and deprecated, to give other apps a chance at testing.

Many of the LINUX hosts are CPU only high core count systems. And even those that have a usable GPU, many don't appear to be making use of it for Numberfields work, and many of them have 200, 500 and even 1,000 Task caches.
My two Windows systems in that are both in the Top 20 and are both set to do the test Tasks if available, but have yet to pick up any.

With 480,000 Tasks ready to send, and a huge number of high throughput CPU LINUX hosts with large caches to feed, 1,000 Tasks is but a drop in the ocean...

---

Grant
Darwin NT, Australia.