Hi,

I tested the new version with a number of the xyyxf project:

[code]
// C123_138_87 (wanted)
762966644474084865482278024025086505334452875335272846616599251317527488358065433787535700689603506179070378980572818254971
[/code]

I made the following batch file

[code]
msieve -s save.txt -v 762966644474084865482278024025086505334452875335272846616599251317527488358065433787535700689603506179070378980572818254971
[/code]

And this is the output from my log file:

[code]
Mon Jun 20 11:40:06 2005
Mon Jun 20 11:40:06 2005
Mon Jun 20 11:40:06 2005 Msieve v. 1.00
Mon Jun 20 11:40:06 2005 random seeds: fd345190 c712c334
Mon Jun 20 11:40:06 2005 factoring 762.....54971 (123 digits)
Mon Jun 20 11:40:13 2005 using multiplier of 1
Mon Jun 20 11:40:13 2005 using sieve block of 65536
Mon Jun 20 11:40:13 2005 using a sieve bound of 3207623 (115500 primes)
Mon Jun 20 11:40:13 2005 using large prime bound of 962286900 (29 bits)
Mon Jun 20 11:40:13 2005 using double large prime bound of 14789320006017000 (44-54 bits)
Mon Jun 20 11:40:13 2005 using trial factoring cutoff of 68 bits
Mon Jun 20 11:40:13 2005 fatal error: poly selection failed
[/code]

Can anybody verify this?? Is this normal?

Update: I also tried number of the oddperfect site & the site of michaël klasson. The client also fails with the poly section error.

My pc:

P4 - 2.4 Ghz with 512mb ram

See Jason's most recent posting: msieve is limited to composites of at most 125 decimal digits. For numbers >110 digits or so you should use GNFS instead.

Alex

For a P4, the size where ggnfs is faster than msieve is even lower - somewhere around 100 digits.

[QUOTE=CedricVonck]Mon Jun 20 11:40:13 2005 fatal error: poly selection failed

Can anybody verify this?? Is this normal?[/QUOTE]
No, it's a limit that should have been raised to properly handle very large inputs.

The source and binary have both been updated; I've verified that your number now starts sieving and actually finds a few relations.

Sorry 'bout that,
jasonp

[QUOTE=jasonp]No, it's a limit that should have been raised to properly handle very large inputs.

The source and binary have both been updated; I've verified that your number now starts sieving and actually finds a few relations.

Sorry 'bout that,
jasonp[/QUOTE]

Jason,

Wich hardware do you have?
FWIW, I am running on Windows XP Pro Sp 2
P4 2.4 ghz with 512 mb ram
That is bizarre

[QUOTE=CedricVonck]
Wich hardware do you have?
FWIW, I am running on Windows XP Pro Sp 2
P4 2.4 ghz with 512 mb ram
That is bizarre[/QUOTE]
Not really. To get technical, SIQS lumps together many small primes when choosing polynomials to sieve over. The code assumed you'd never need more than 16 small primes, but your input required 17. I just raised the limit to 20. It's not a hardware thing, just a limit set too low in the code.

My main test machine is 1 GHz athlon thunderbird running win98. For big tests I use a dual 2GHz opteron running 64-bit redhat FC2.

jasonp

[QUOTE=Mystwalker]For a P4, the size where ggnfs is faster than msieve is even lower - somewhere around 100 digits.[/QUOTE]

I've found the limmit even lower on my pentium M notebook.
96-97 digits is generally faster with GNFS

[QUOTE=jasonp]To get technical, SIQS lumps together many small primes when choosing polynomials to sieve over. The code assumed you'd never need more than 16 small primes, but your input required 17. I just raised the limit to 20. It's not a hardware thing, just a limit set too low in the code.

jasonp[/QUOTE]

Do you plan a v 1.01 or a 1.00 rc2? :whistle:

Luigi

[QUOTE=ET_]Do you plan a v 1.01 or a 1.00 rc2? :whistle:

Luigi[/QUOTE]
I should have been more explicit about this, but when I announced that I'd updated the code and binary it was after I updated my web page. The change was so tiny I didn't feel like raising the version number, so it's still 1.0

jasonp

[QUOTE=smh]What c114 are you talking about?[/QUOTE]
889833778365299681909545910637910413314383844662549129190\
978654159771037580484106809149320857746132835988414179957,

a factor of 115^19+19^115.