Let's attack the Bayesian-ECM-bounds again - Page 3

EdH · 2016-10-01, 01:34

OK, I haven't got a clue what I'm doing:

Code:

[duser@localhost ecmScripts]$ python ecm-toy.py g162 100@11e6 pc1
Traceback (most recent call last):
  File "ecm-toy.py", line 161, in <module>
    load_datafiles(machine)
  File "ecm-toy.py", line 136, in load_datafiles
    ecm_times[idx][1].append([int(ls[1].strip()), get_time(ls[idx+2])])
  File "ecm-toy.py", line 92, in get_time
    mytime += float(x[:-2])
ValueError: invalid literal for float(): 768.336s

linux Fedora, Python:

Code:

Python 2.7.10 (default, Jun 20 2016, 14:45:40) 
[GCC 5.3.1 20160406 (Red Hat 5.3.1-6)] on linux2

I made your two changes and added some pc1 (totally inaccurate) timings to gnfs-timings.txt.

wombatman · 2016-10-01, 03:29

It's the line endings. I had to use Notepad++ to convert them from Windows to Unix format. Then that error went away.

henryzz · 2016-10-01, 09:57

I should also point out that g162 doesn't get detected as gnfs. You need G162.

EdH · 2016-10-01, 13:11

I'm still not getting anywhere with any of the versions. Or, I'm not understanding what I am getting. This is from ecm-toy_wx01.zip:

Code:

[duser@localhost ecmScripts]$ python ecm-toy.py G162 1000@110e6 tractor
Expected NFS time is 188.026 days
prior = {30: 0.019697635393393594, 31: 0.019689924488298982, 32: 0.019682772110834114, 33: 0.019676121571714472, 34: 0.019669923474612935, 35: 0.019664134592095563, 36: 0.019658716941776712, 37: 0.019653637022497207, 38: 0.019648865179259605, 39: 0.019644375072419822, 40: 0.019640143231801306, 41: 0.019636148680373767, 42: 0.019632372615220613, 43: 0.019628798135924413, 44: 0.019625410012389235, 45: 0.019622194485611835, 46: 0.019619139096100816, 47: 0.019616232535591756, 48: 0.019613464518469063, 49: 0.019610825669921048, 50: 0.019608307428354736, 51: 0.01960590196000455, 52: 0.01960360208400262, 53: 0.019601401206453175, 54: 0.01959929326228, 55: 0.019597272663803827, 56: 0.019595334255163015, 57: 0.01959347327182121, 58: 0.01959168530451516, 59: 0.01958996626708781, 60: 0.0195883123677294, 61: 0.019586720083214642, 62: 0.019585186135780145, 63: 0.01958370747233318, 64: 0.019582281245723563, 65: 0.01958090479784497, 66: 0.019579575644361552, 67: 0.019578291460881324, 68: 0.01957705007041974, 69: 0.019575849432015954, 70: 0.01957468763038043, 71: 0.01957356286646732, 72: 0.019572473448876953, 73: 0.019571417786004915, 74: 0.019570394378863525, 75: 0.019569401814509894, 76: 0.019568438760021692, 77: 0.019567503956968674, 78: 0.019566596216333, 79: 0.01956571441383675, 80: 0.019564857485639242}
Traceback (most recent call last):
  File "ecm-toy.py", line 215, in <module>
    t_one_curve = interpolate_list(entry, targdig)
  File "ecm-toy.py", line 82, in interpolate_list
    (M,e)=fitexp_list(listy[1])
  File "ecm-toy.py", line 50, in fitexp_list
    (m,c)=fitlin(dl)
  File "ecm-toy.py", line 32, in fitlin
    ssxx = sxx - sx*sx/s;
ZeroDivisionError: integer division or modulo by zero

I have changed all the .txt documents to linux line-endings, one instance of R.sort() to R=sorted(R) and one instance of xrange to range.

I'm not trying to be too obnoxious, but why would the last examples shown (in posts 18 and 20) use a g, if a G is required?

henryzz · 2016-10-01, 13:34

tractor doesn't have any ecm-timings using the format that WraithX's version uses. This means that the array is empty and in turn causes a division by zero.
Change the pc to pc1 from tractor and try again.
Frustratingly there are only gnfs timings for tractor and not pc1. I would suggest renaming the values for tractor to pc1 for now. We will have to calculate some values on the same pc at some point. Without this G wont work.

If you look in the source G is what is checked for not g and anything else is treated as snfs. Could you do a 250 digit gnfs in ~800 days on one core as shown in post 18? 3.8 million days is a little more realistic.

EdH · 2016-10-01, 14:25

Quote:

Originally Posted by henryzz

tractor doesn't have any ecm-timings using the format that WraithX's version uses. This means that the array is empty and in turn causes a division by zero.
Change the pc to pc1 from tractor and try again.
Frustratingly there are only gnfs timings for tractor and not pc1. I would suggest renaming the values for tractor to pc1 for now. We will have to calculate some values on the same pc at some point. Without this G wont work.

If you look in the source G is what is checked for not g and anything else is treated as snfs. Could you do a 250 digit gnfs in ~800 days on one core as shown in post 18? 3.8 million days is a little more realistic.

Thanks for your patience. It is working and I almost understand it now (maybe)...

wombatman · 2016-10-15, 17:16

I'm having an issue with the tool at higher B1 values:

Code:

 python ecm-toy.py S286 1408@850e6 pc1

gives an overflow error:

Code:

Traceback (most recent call last):
  File "ecm-toy.py", line 203, in <module>
    posterior = update(prior, sz_done, n_done)
  File "ecm-toy.py", line 173, in update
    posterior[k] = prior[k] * (1-sp)**count
OverflowError: (34, 'Numerical result out of range')

sp is 3.26(more digits) and count is 1408. If I set count to 100, it works fine, though it takes a bit longer. Is there a simple solution here?

fivemack · 2016-10-15, 21:21

Quote:

Originally Posted by wombatman

I'm having an issue with the tool at higher B1 values:

Code:

 python ecm-toy.py S286 1408@850e6 pc1

gives an overflow error:

Code:

Traceback (most recent call last):
  File "ecm-toy.py", line 203, in <module>
    posterior = update(prior, sz_done, n_done)
  File "ecm-toy.py", line 173, in update
    posterior[k] = prior[k] * (1-sp)**count
OverflowError: (34, 'Numerical result out of range')

sp is 3.26(more digits) and count is 1408. If I set count to 100, it works fine, though it takes a bit longer. Is there a simple solution here?

What does your ecm-probabilities.txt file look like? I can't see how this could happen without the line for 850 in that file having a positive rather than negative exponent - 'sp' should be a success probability.

Ah! Have you maybe modified the range of prior probabilities to start somewhere after 30? The success probability is coming from an exponential fit, and if the digit count is less than 29 then it will give a meaningless probability. Change the success_prob function to return 1 if the value that it would have been returning is greater than 1.

wombatman · 2016-10-16, 01:57

ecm-probabilities.txt looks like this:

Code:

# fits to ECM probabilities as produced by gmp-ecm
250e3	339558	-0.59945
1e6	112752	-0.51792
3e6	140924	-0.4849
11e6	158805	-0.44906
43e6	157430	-0.41522
110e6	199840	-0.398221
260e6	112663	-0.372375
850e6	134282	-0.354108
2.9e9	134916	-0.334493

As far as I can recall, I haven't modified it at all. Nor have I modified the range of prior probabilities (at least, not intentionally).

Changing the success_prob function, however, to this:

Code:

if((ecm_success_factor[B1] * exp(digits*ecm_success_exponent[B1])) > 1):
		return 1
	else:
		return ecm_success_factor[B1] * exp(digits*ecm_success_exponent[B1])

got it to work, as you suggested. Thanks!

fivemack · 2016-10-16, 10:49

Quote:

Originally Posted by wombatman

ecm-probabilities.txt looks like this:

Code:

# fits to ECM probabilities as produced by gmp-ecm
250e3	339558	-0.59945
1e6	112752	-0.51792
3e6	140924	-0.4849
11e6	158805	-0.44906
43e6	157430	-0.41522
110e6	199840	-0.398221
260e6	112663	-0.372375
850e6	134282	-0.354108
2.9e9	134916	-0.334493

As far as I can recall, I haven't modified it at all. Nor have I modified the range of prior probabilities (at least, not intentionally).

That's interesting, because it's completely different from the version I have and have distributed! I wonder where it came from

wombatman · 2016-10-16, 16:56

I think it's the one that WraithX worked up, because I also used the gen_ecm_times python script.

2016-10-15, 17:16	#29
wombatman I moo ablest echo power! May 2013 13×137 Posts	I'm having an issue with the tool at higher B1 values: Code: python ecm-toy.py S286 1408@850e6 pc1 gives an overflow error: Code: Traceback (most recent call last): File "ecm-toy.py", line 203, in <module> posterior = update(prior, sz_done, n_done) File "ecm-toy.py", line 173, in update posterior[k] = prior[k] * (1-sp)**count OverflowError: (34, 'Numerical result out of range') sp is 3.26(more digits) and count is 1408. If I set count to 100, it works fine, though it takes a bit longer. Is there a simple solution here?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Nuke attack - run or hide?	MooMoo2	Soap Box	40	2018-01-19 23:48
What Bounds to choose, and what are Bounds	144	Information & Answers	5	2017-03-15 13:36
GPU attack on double Mersennes?	Uncwilly	GPU Computing	29	2013-09-08 20:53
Attack of the Cosmic Rays	S485122	Hardware	3	2010-08-24 01:19
Attack of the Killer Zombies	ewmayer	Lounge	12	2007-01-30 05:56

2016-10-01, 03:29	#24
wombatman I moo ablest echo power! May 2013 13×137 Posts	It's the line endings. I had to use Notepad++ to convert them from Windows to Unix format. Then that error went away.

2016-10-01, 09:57	#25
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 16FE₁₆ Posts	I should also point out that g162 doesn't get detected as gnfs. You need G162.

2016-10-01, 13:34	#27
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 2×3³×109 Posts	tractor doesn't have any ecm-timings using the format that WraithX's version uses. This means that the array is empty and in turn causes a division by zero. Change the pc to pc1 from tractor and try again. Frustratingly there are only gnfs timings for tractor and not pc1. I would suggest renaming the values for tractor to pc1 for now. We will have to calculate some values on the same pc at some point. Without this G wont work. If you look in the source G is what is checked for not g and anything else is treated as snfs. Could you do a 250 digit gnfs in ~800 days on one core as shown in post 18? 3.8 million days is a little more realistic.

2016-10-16, 16:56	#33
wombatman I moo ablest echo power! May 2013 6F5₁₆ Posts	I think it's the one that WraithX worked up, because I also used the gen_ecm_times python script.