[QUOTE=bsquared;279505]Posts 951-968 describe methods to do just that.[/QUOTE]

Also, the new version has the -p switch to force yafu to run at idle priority (and, I assume, any processes it spawns like ggnfs or ecm).

@bsquared: [URL="http://www.hoopsandyoyo.co.uk/pages/ecards.php?code=43&action=view&history=5"]That for you![/URL]

:smile::smile::smile:

I let it get up to 400 or so... it sounded like they were getting out of breath :smile:

Hehe, you won't believe it, but some idiot let it play to 1M just to see how it ends.

Man! that should be more difficult than factoring numbers! :smile:

It turns up that is [URL="http://www.youtube.com/watch?v=1dkhZhCryX0&feature=related"]does not end[/URL]. The counter just runs forever. Reading the comments is an eternal source of fun in itself, when the guys starting to say "mine is 300 thousands", "mine is 475332", etc.

Next step should be to take it to 2^31, or 2^63, to see what the flash payer is doing when the overflow happens (depends of the data type that the designer used). It will either crash, or it will display two billions of [B]negative[/B] "thankyous". :grin:

Could not edit previous post to add to it, the "1 hour time limit".

Now, taking back 1.3% of the thankyous. You still have 987k left.

I just superficially read the docfile, and replaced old exe with the new exe. Everything works except nfs, which crashes in "commencing polynomial search over range: 0-xxx" with a debug exception. I was keeping the same yafu.ini file. Do I need to change some paths, or dld new upgrades for ggnfs?

Remark: "yafu tune()" works, but "yafu nfs(rsa(xxx))" with xxx around 280-300, works only when the factoring does not come up to nfs (it switches to siqs). If it comes to nfs, then the window of "VS-just-in-time debugger" pops up. It says "an unhandled exception blablalba occured in yafu.exe", and asks me if I want to debug. I have to answer "no, thanks":smile:. Bothering. Then it crashes. Bothering again...

I tried nfs with one thread only, (due to the "setting threads = 1 for tunning" message, I imagined it could be related to this). Still exception+crash.

Running WinXP32 currently, on a core2duo(64bit), so I only could try yafu-32k-win32 and yafu-64k-win32. When I get home in the evening I will try the other two (64 bit OS versions) on both Win7/64 and Vista64.

Interesting that "tune" results are totally different from the old version. It seems that nfs is a bit faster and siqs is a bit slower for 1.29, on exactly the same hardware as before. That could be good, or could be bad... or could be a wrong impression caused by the fact the the cutoff point is in fact the intersection of two curves and only one curve moved a bit... I am still considering my 4000++ hours for a siqs in 130 range :P:P:boxer:

There is also a huge difference in tune results between y32w32 and y64w32, but I assume this is normal, did not check how it was for 1.28 at that time.

Same result when trying to use "testrange". What I am doing wrong??
How come that the "tune" command works without exception???

Now, as it is not my style to put a post with only 2 lines of text, I could use the opportunity to suggest a small speed improvement: we should have a flag to suppress printing on screen for poly selection phase. If I redirect the output to null, then the selection phase is faster and always generates better polynomials. To make sure, I maped a ram-disk "X:" and I redirect the output to it, it tested a lot more polynomials (using v1.28, as v1.29 still can't run nfs). This can be easily tested if you minimize the window and let it running for one minute, when you restore it, it will say "poly 1200" or so, but if you let the window on screen to scroll, after 1 minute it can only reach "poly 800" or so. Printing/scrolling the screen takes a lot of time, and by suppressing it, you could make the selection phase faster.

Hello LaurV,

I have just tested the latest version of YAFU on Windows 7 with the sort of inputs you mention and it works fine for me. If you want to test whether your YAFU binaries are OK, I can send you the versions I am using. If you wish to do this, PM me with an email address to use (can you ZIP/UNZIP?) as the file will be quite large.

[QUOTE=Brian Gladman;279564](can you ZIP/UNZIP?)[/QUOTE]
I took this as a good joke, as the files on the provided link are already zipped. If I could not unzip, then I could not install them. And I don't believe there is someone who actually can't unzip here around, so I did all the efforts to exclude the irony and take the funny side of it. Thanks anyhow for the offer to help. Second, if the files are tampered, they won't unpack right (crc errors). And moreover, it will not run the "tune" part, and everything else except nfs poly selection and testrange. My money are on a bug. And third, if they run in your computer, does not prove that they run, only that your computer can't detect the exception properly, or you don't have the level of protection high enough. When you run software done by third parties you should be armored to your neck against viruses, trojans, accidental programming errors, or "intended" programming errors, that can cause harm to your data and/or hardware. And I am quite paranoid about that. As I said before, my thesis was in computer viruses and data protection.

Coming back to yafu, after I ended my working day and I arrived home I tested both x64 versions on Win7/64 AND Vista/64. They work without any problem. As I have same ggnfs binaries, the problem is not related to them. I also tested again the yafu32win32 on a older laptop (32 bit processor, I can't test yafu64win32 on this laptop). It continue to pop up the unhandled exception (VS2005-JIT debugger this time, which is installed there) and to crash soon after poly selection starts.

Not a joke as I have no idea where you get your binaries from (or what form they come in). The potential problem on which I was offering help is that of binaries that are wrongly compiled or compiled with the wrong run-time library. The binaries that I run are not the same as those you are using since I build them myself from the YAFU repository. So I am not running downloaded binaries, something I avoid as far as possible for the reasons you give.

I see the Win32 crash too. I remembered to tell you that a period of several days after any version release should be considered a "beta testing" phase right?

"tune" works because it does not attempt to run poly selection, only the ggnfs sievers, and it seems the problem is in the poly selection phase, and only for win32.

As for the relative speed of the two algorithms, siqs was ported to using gmp primitives instead of my homegrown ones for bigint math. Its hard to be sure due to measurement variation, but I did notice a potential 1-2% slowdown as a result of this for the win32 binaries.

@Brian: Well, sorry for being harsh. I better wait for bsquared to fix it, now as he confirmed it. Otherwise I would happily take your binaries. Unfortunately I can't compile yafu, I only have VS2005, my daily job is WinCE and generally microcontroller programming, and that is the last version that includes Platform Builder for CE, licensed by our company (ulterior versions of VS had PB as a separate plugin, more difficult to use). I did not find the time yet to play with VS2008/2010, with all the shame that could result from saying that.:blush:

Now, the only computer affected by yafu v1.29 bug is the one at work. Everywhere else I run win64. That computer still can wait, or it still can run the old version, or better I will give some P95 to it to do (anyhow I was thinking of unreserving aliquot 585000, as it is almost "too high" for me to handle now, and it still keeps the driver, but this I am stil considering it).