[quote=jasonp;191047]Wait until you have to fix a bug in a long division routine :)[/quote]

Uggh, yeah, that's where I thought it was at first becuase the debugger caught the integer overflow in an __asm div statement. Luckily it didn't take long to narrow it down to the normalization done prior to long division :)

Yafu 1.12
 

now available [URL="http://bbuhrow.googlepages.com/home"]here[/URL]

[FONT=Arial][SIZE=2]New in Version 1.12[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ bugfixes[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ enable use of optional yafu.ini file to override default settings[/SIZE][/FONT]
[FONT=Arial][SIZE=2]+ added some smartness to how many ECM curves are run based on estimated QS time (only happens when using factor()). Some diagnostic comments are enabled still as I expect this won't work well everywhere.[/SIZE][/FONT]

[FONT=Arial]If the amount of time spent in ECM seems wrong, let me know by posting or emailing the screen info. The ratio of ECM to SIQS time (printed after siqs finishes) should be less than 0.25.[/FONT]
[FONT=Arial][/FONT]
[FONT=Arial]p.s.[/FONT]
[FONT=Arial]Big thanks to Brian Gladman for help doing cpu frequency estimation in windows. linux people... I hope what i have works ok to estimate cpu frequency and thus get the qs time estimate right. It works for the few machines I've tried it on.[/FONT]

[FONT=Arial]- ben.[/FONT]

Although the cpu speed on Windows is now reported correctly, the timing code is in error because it is built on the assumption the Windows QueryPerformanceCounter() call returns the value of the Time Stamp Counter, which it doesn't always do. Hence Ben's ECM (and other) timing measurements on Windows will often be completely wrong.

I am reporting this here because it may well make the reporting ECM/SIQS timing ratios unproductive on Windows. Moreover I don't think Ben will get back to this until next week.

[quote=bsquared;191094][FONT=Arial]p.s.[/FONT]
[FONT=Arial]Big thanks to Brian Gladman for help doing cpu frequency estimation in windows. linux people... I hope what i have works ok to estimate cpu frequency and thus get the qs time estimate right. It works for the few machines I've tried it on.[/FONT][FONT=Arial][/FONT][/quote]
It seems to work OK on my i7 running Fedora 11 x86_64:
[code]***** cpu looks to be about 2672.719800 MHz[/code]

You use rdtsc, so you won't be able to detect i7 turbo frequencies. I have found no way of detecting the real frequency :no:

Although the changes file notes "improved Nroot, much less hackish" the nroot function is still rather buggy and slow. There are (at least) three types of bugs (only one typical example is given for each type).

System is Win2000, exe file is yafu-32k-Win32.exe.

09/27/09 21:01:44 v1.12 @ ZAPHOD,
Initializing with Tom's Fast Math (x86-32 asm)...
cached 78504 primes. pmax = 1000099
detected cpu 4, with L1 = 8192 bytes, L2 = 262144 bytes

1. off by one error:
>> nroot(5^3,3)
ans = 4

2. totally wrong answer after long time (10 sec), note that 3^180 has only 286 bits, i.e. no overflow etc. should happen:
>> nroot(3^180,180)
ans = 0

3. Crash:
>> nroot(-8,3)

Gammatester

[quote=Brian Gladman;191107]Although the cpu speed on Windows is now reported correctly, the timing code is in error because it is built on the assumption the Windows QueryPerformanceCounter() call returns the value of the Time Stamp Counter, which it doesn't always do. Hence Ben's ECM (and other) timing measurements on Windows will often be completely wrong.

I am reporting this here because it may well make the reporting ECM/SIQS timing ratios unproductive on Windows. Moreover I don't think Ben will get back to this until next week.[/quote]

I'm back now, and should get some time to look into the new code you sent this week. I haven't heard from anyone yet saying the current version is not working...

[quote=Gammatester;191259]Although the changes file notes "improved Nroot, much less hackish" the nroot function is still rather buggy and slow. [/quote]

I'd argue it's all of these things :razz:.

nroot has been a thorn in my side for a while, all the more so because it shouldn't be... the algorithm is simple and easy to code. The problem is when I try to make it fast by doing a double precision estimate of the leading digits of the answer - I end up fouling it all up.

I'll try again, thanks for your testing.

- ben.

Would looking at the msieve version be helpful? (Getting an initial estimate was a major pain for me too)

[quote=jasonp;191390]Would looking at the msieve version be helpful? (Getting an initial estimate was a major pain for me too)[/quote]

Yes, it was helpful, and I think that part is working now. [url=http://www.mersenneforum.org/showthread.php?t=12516]But turns out it is a different problem[/url].

Bsquared, I just factored 120024621595864025218910923338006229301425391924739107060397489618540260099717126712633721435874689
to [COLOR=#000000]2925384400770993343049563645260155764299463512577[/COLOR] and [COLOR=#000000]41028666716152310208039084132300909697472499651457 in few hours with Yafu 1.12. Thank you.
[/COLOR]

Hi!

Trying to factor C143 number,

it it possible to split working between 4 PC?
8x4core Q6600 think can improve time consumption, but how to do this correctly?

I set Threads=4 on each PC, but what about dividini relation' space?

tanx