The new binary nailed all three. Thanks!

In the end, when all factors are reported, the binary lingers for a second and then says
[FONT=Arial Narrow]>> couldn't reallocate string when parsing
Exit 255[/FONT]
It doesn't hurt (really), but what is it doing for that second?
[COLOR=green]The command-line is[/COLOR]
[FONT=Arial Narrow][COLOR=green]# echo "siqs(732566077883908909845195639793682175206731)" | yafu -v[/COLOR][/FONT]

Doesn't seem to "freeze" without -v.

[quote=bsquared;212370]Who knew that the ultimate question to the ultimate answer was "what size composite integer places excessive stress on yafu's hack of a random number generator?"? Only for 64 bit systems is this a problem, where I put some garbage together to try to extend rand() to produce a 64 bit random number rather than the 16 bit default.[/quote]If you want a cheap and cheerful 64-bit PRNG I recommend the MMIX LCG:
[code]x[i+1] = (6364136223846793005*x[i] + 1442695040888963407) mod 2^64[/code]

If you want a good generator you need to do a bit more research.


Paul

[QUOTE=Batalov;212371] The new binary nailed all three. Thanks!

In the end, when all factors are reported, the binary lingers for a second and then says
[FONT=Arial Narrow]>> couldn't reallocate string when parsing
Exit 255[/FONT]
It doesn't hurt (really), but what is it doing for that second?[/QUOTE]

Putting in a few cycles on computing the Ultimate Question, of course :smile:.


[QUOTE=Batalov;212371]
[COLOR=green]The command-line is[/COLOR]
[FONT=Arial Narrow][COLOR=green]# echo "siqs(732566077883908909845195639793682175206731)" | yafu -v[/COLOR][/FONT]

Doesn't seem to "freeze" without -v. [/QUOTE]

On a more serious note, would you be upset to learn that it was stuck in a loop allocating more memory for a string? malloc eventually returns NULL, at which point the program notices and exits.

Everything works fine without the -v because the program is able to determine that there is something in the pipe, processes it, and exits. It gets confused with the -v because there is both something in the pipe and an input argument which causes it to open in interpreter mode. There is apparently a neverending stream of stuff coming out of an open pipe... :redface:.

A workaround until I can fix this is to just use yafu "siqs(732566077883908909845195639793682175206731)" -v, or use echo but put the v in the .ini file.

apologies,
- b.

[QUOTE=xilman;212376]If you want a cheap and cheerful 64-bit PRNG I recommend the MMIX LCG:
[code]x[i+1] = (6364136223846793005*x[i] + 1442695040888963407) mod 2^64[/code]

If you want a good generator you need to do a bit more research.


Paul[/QUOTE]

Such as [URL="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html"]this[/URL]?

[quote=bsquared;212407]Such as [URL="http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/emt64.html"]this[/URL]?[/quote]Sure, if it meets your requirements. I don't know what "good" means in your context.

Until you know your requirements (speed, cycle length, cryptographic strength, code complexity, sundry statistical properties, etc) it is difficult to give advice other than to conduct research.

The 3rd Edition of Numerical Recipes has some nice proposals for non-cryptographic PRNGs.

My guess is that the MMIX may be sufficient for what you want, which is why I proposed it. It is certainly very quick to write and to run as it consists of two simple arithmetic operations on a 64-bit variable. It's what I use all the time when I can't justify anything more complex.

Paul

[QUOTE=xilman;212419]Sure, if it meets your requirements. I don't know what "good" means in your context.[/QUOTE]


That's a good question; me neither, really. Random numbers are used in many places throughout the code, but mostly for non-critical things like generating random ECM curve sigmas and random factor base indices from which SIQS polynomials are built, that sort of thing. MMIX, I'm sure, would be fine for those.

The only "mission critical" application from a RNG standpoint that I can think of is the RSA number generation function. But I've never meant that to be targeted for cryptographic use - only for generating test cases for siqs and other factoring routines.

[QUOTE=xilman;212419]
It's what I use all the time when I can't justify anything more complex.

Paul [/QUOTE]

Sounds a lot like my situation.

Thanks!
- ben.

[QUOTE=bsquared;212407][QUOTE=xilman;212376]If you want a cheap and cheerful 64-bit PRNG I recommend the MMIX LCG:
[code]x[i+1] = (6364136223846793005*x[i] + 1442695040888963407) mod 2^64[/code]

If you want a good generator you need to do a bit more research.


Paul[/QUOTE]Such as [URL="http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt64.html"]this[/URL]?[/QUOTE]

Or [url=http://burtleburtle.net/bob/rand/isaacafa.html]this[/url]?

[QUOTE=jrk;216033]Or [url=http://burtleburtle.net/bob/rand/isaacafa.html]this[/url]?[/QUOTE]

Thanks! I hadn't seen that before.

Suggestion:

The output from yafu V1.18 in a DOS-box gives the length of the candidate like
rho: ... on C99
pp1: ... on C99
ecm: ... on C99 ...

but the file 'factor.log' only prints this in bit-size!

So could you equalize both outputs? I like the Cxx more.

[QUOTE=kar_bon;218152]Suggestion:

The output from yafu V1.18 in a DOS-box gives the length of the candidate like
rho: ... on C99
pp1: ... on C99
ecm: ... on C99 ...

but the file 'factor.log' only prints this in bit-size!

So could you equalize both outputs? I like the Cxx more.[/QUOTE]

Sure, thanks for the suggestion.

YAFU 1.19 available
 

... in the [URL="http://sites.google.com/site/bbuhrow/"]usual place[/URL].

New in version 1.19

+ much improved sieve of Eratosthenes
+ faster prime counting (fastest available on modern 64 bit CPUs in some situations)
+ higher limit (up to 4e18)
+ less memory usage
+ some new flags for printing primes.
+ slightly faster SQUFOF implementation
+ bugfixes
+ misc requested changes
+ addition of fermat's factorization algorithm

For this version I again mostly concentrated on the sieve of Eratosthenes. Also the usual bug fixes and requested changes. Any feedback is welcome.