The --platform=1 option is still ignored.
(and additionally, the existence of -f and -F options is denied by the program)
[CODE]$ ./xyyxsievecl64.exe --platform=1 -x2 -X2500 -y7000 -Y7500 -P1e6 -t1 -s2000 -S+ -oxyyx.pfgw -f1 -F1
xyyxsievecl v1.0.1, a GPU program to find factors numbers of the form x^y+y^x
Quick elimination of terms info (in order of check):
626000 because the term is even
118610 because x and y have a common divisor
357496 because the term is divisible by a prime < 100
List of available platforms and devices
C:\Users\Serge\Desktop\XYYXsieve\xyyxsievecl64.exe: invalid option -- F
C:\Users\Serge\Desktop\XYYXsieve\xyyxsievecl64.exe: invalid option -- 1
[U]Platform 0 has no available devices.[/U] Here is a list of platforms and devices:
Platform 0 is a Advanced Micro Devices, Inc. AMD Accelerated Parallel Processing, version OpenCL 1.2 AMD-APP (938.2)
No devices
Platform 1 is a NVIDIA Corporation NVIDIA CUDA, version OpenCL 1.1 CUDA 6.0.1
Device 0 is a NVIDIA Corporation GeForce GTX 570[/CODE]Says: "[U]Platform 0 has no available devices[/U]", does not switch to platform 1 (even though instructed) and quits.

Also, minor: there is no line break after "Here is a list of platforms and devices:" message.

I didn't change the version number, but this should be 1.0.2.

I finally tracked down and fixed the main "Out of resources" issue. I'm referring to the one that impacts large search ranges. I wasn't reinitializing a variable in a loop.

I fixed some issues with continuing from a previous output file.

I don't know why --platform doesn't work so I need to investigate that, but -f should now work to change the platform (although I haven't tested it).

I spoke too soon on the "Out of resources" issue. I thought I had nailed it, but I just one with the latest build. :censored:

[QUOTE=rogue;377570]It appears that MultiSieve removes terms for which it does not have a factor. [/QUOTE]
Just curious if this was only for xy+-yx?
Was it by any chance a problem for GC/GW sieves?

[QUOTE=Batalov;377684]Just curious if this was only for xy+-yx?
Was it by any chance a problem for GC/GW sieves?[/QUOTE]

I don't understand your question. This program is specific for x^y+/-y^x. MultiSieve is more generic. Almost every component of MultiSieve is now done much faster by other software. For example, gcwsieve is the preferred siever for Generalized Cullens and Generalized Woodalls.

n*b^n+/-1 uses a discrete log. x^y+/-y^x does not use a discrete log.

[QUOTE=rogue;377570]It appears that MultiSieve removes terms for which it does not have a factor. I've looked at the code and have not been able to figure out where that is occurring. This means that ranges sieved in the past should be sieved again presuming I can't track down why it is doing it, which I have little desire to do.[/QUOTE]
My question was about good old MultiSieve (because you wrote about MultiSieve's behavior). I quoted specifically the statement for which I had a followup question.

gcwsieve is (of course) faster, but some legacy GC/GW projects may have been done with MultiSieve (some bases were done more than ten years ago). But if under-reporting behavior was limited to the xyyx branch of MultiSieve only, then there shouldn't be any problem.

[QUOTE=Batalov;377715]My question was about good old MultiSieve (because you wrote about MultiSieve's behavior). I quoted specifically the statement for which I had a followup question.

gcwsieve is (of course) faster, but some legacy GC/GW projects may have been done with MultiSieve (some bases were done more than ten years ago). But if under-reporting behavior was limited to the xyyx branch of MultiSieve only, then there shouldn't be any problem.[/QUOTE]

Yes, they use completely different logic. They do share some lower level code, but that code is not where the bug is. If it were, then it would have manifested itself when comparing MultiSieve output to gcwsieve output.

Right!

I think multisieve ("start new sieve" option) is still faster than the setup accessory sieve gcwsieve-1.3.5-smallp.zip (or Pari ad hoc) ... but then (after p>N) one should switch to gcwsieve.

The interval 20,001<=x<=40,000, 201<=y<=400 is reserved by Norbert Schneider.

Please ensure that he is not using MultiSieve due to the undiagnosed bug described earlier in this thread.

As I stated above I am sieving all y for all x < 10000 (using your nomenclature) and intend to retest to determine if any PRPs were missed.

I just checked in changes for PRPNet into sourceforge. It now supports x^y+y^x and x^y-y^x searches.