There are only two intended high level differences.

First, I added the ability to input and convert a polynomial in msieve format (at Jeff Gilchrist's suggestion). Second I changed the minrels - this process is still underway though, so expect more changes.

I think all the bugs have so far been introduced by me. I don't recall deliberately solving any bugs in the Perl but there are some significant changes in the siever management that might have had an impact.

The logging is much improved although more needs to be done.

Brian

Does factMsieve.py resume after a "matrix probably cannot build" or "matrix must have more columns that rows" error?

Anyway, here are some figures for 25-bit large primes (done with .pl script). A gap in MINRELS.txt means that either I did not make a MINRELS.txt file, or I deleted it, which I did a couple of times. Below 89 digits I do QS.

[code][b]Size LeadingDigits MINRELS.txt Raw Unique[/b]
89 1131 1800000 1803052 1675159
89 4830 1750000 1764474 1615053
89 7634 1750000 1763240 1625893
90 1439 1800000 1809018 1684321
90 1874 1760293 1617264
90 2072 1750000 1771944 1638743
90 4847 1700000 1704923 1574201
90 8993 1750000 1762898 1612751
91 1165 1833307 1766909
91 1620 1800000 1841421 1650684
91 2351 1894921 1823378
91 3712 1750000 1847143 1690302
91 4295 1750000 1759810 1593467
91 6384 1750000 1758365 1592276
91 8532 1700000 1755437 1585167
91 8678 1821417 1718767
92 1466 1851206 1754358
92 1570 1800000 1865550 1646612
92 4666 1750000 1792690 1606020
92 4825 1883883 1773088
92 7846 1934917 1844905
93 1059 2001740 1969550
93 1178 2084048 2044713
93 1595 2000000 2079944 1926148
93 1837 1850000 1899691 1803171
93 2940 2148525 2027377
93 3730 1919338 1773812
93 4242 1900000 1958288 1806365
93 6582 1800000 2034718 1833558
94 2204 1854290 1812732
94 7392 2128887 1976645
94 7950 2149444 1998208
94 8589 2402680 2231129
94 9041 2134253 1998797
94 9540 1902822 1843788
95 1176 2052137 1922902
95 1354 1961578 1901425
95 1395 2000000 2041882 1961371
95 1478 1800000 2135476 2002810
95 1869 1900000 2031376 1966301
95 2611 1985692 1922587
96 2848 2051805 1888459
96 4022 2042519 1847721
96 8562 1908825 1733976
97 9761 2030333 1859290[/code]

[QUOTE=EdH;204786]Paul,

I noticed an [URL="http://www.mersenneforum.org/showthread.php?t=12981#12"]earlier posting[/URL] about [URL="http://www.portablepython.com/"]Portable Python[/URL] and am about to see if it will work for my bootable CD/USB project. Have you possibly explored this already?

I will provide more info, if this does work for me.

Alternately, I would be willing to help with a project to update the Perl script, although my knowledge base is rather limited. This would provide me an opportunity to expand it...

Take Care,
Ed[/QUOTE]I mentioned that I had access to a "rather nice" RedHat system.

PortablePython appears to be Windoze only.


Paul

[quote=xilman;204797]I mentioned that I had access to a "rather nice" RedHat system.

PortablePython appears to be Windoze only.


Paul[/quote]
So I'm discovering...:sad: My bootable CD/USB project is linux based.

I also was looking at what it would take to make the current .py script run in the older Python. That may even be easier. But first, I would have to understand Python and what the changes were when it went to 2.6...

Take Care,
Ed

There are probably two things that will cause you most pain.

First, print was changed from a statement to a function and a format function was added to provide output formatting.

Second, I make a lot of use of context statements:

[code]with open(file, mode) as inf:
file operations
.....
[/code]that you will have to change these to file open/close operations:

[code]inf = open(file, mode)
file operations
inf.close()
[/code]There are probably others that I have forgotten about.

Thanks to everyone who has supplied minrels data. The attached version of factmsieve.py uses the supplied data to set minrels for lpbr/a 25, 26 and 27 and the old estimate formula for higher values.

Brian

Thanks Brian,

Both, for the new version and the info on the 2.6 differences.

I might just take on the project of trying to make it work with 2.5, since my attempt yesterday at compiling Python 3.1 crashed, as is often the case when I follow the very straightforward and clear instructions that accompany these packages.:sad: Besides, if I'm trying to save space for my CD/USB project, bringing Python 3.1 into the mix is a step in the wrong direction...

Take Care,
Ed

[quote=EdH;204915]Thanks Brian,

Both, for the new version and the info on the 2.6 differences.

I might just take on the project of trying to make it work with 2.5, since my attempt yesterday at compiling Python 3.1 crashed, as is often the case when I follow the very straightforward and clear instructions that accompany these packages.:sad: Besides, if I'm trying to save space for my CD/USB project, bringing Python 3.1 into the mix is a step in the wrong direction...

Take Care,
Ed[/quote]
I would also be willing to attempt to help make it work in an older version of python. I think it would be quite helpful to have it working in 2.4 as that is what people seem to have by default. We should want it as portable as possible.

Hi Guys,

If you are going to backport it to an earlier version of Python, could one of you decide who is going to maintain it as I won't be able to do this.

In fact my development version is python 3 and when python 2.7 is released not even 2.6 will work as I need something in 2.7 and 3.1 (ordered dictionaries).

Brian

[quote=Brian Gladman;204934]Hi Guys,

If you are going to backport it to an earlier version of Python, could one of you decide who is going to maintain it as I won't be able to do this.

In fact my development version is python 3 and when python 2.7 is released not even 2.6 will work as I need something in 2.7 and 3.1 (ordered dictionaries).

Brian[/quote]
Are you saying you won't be able to run our backport?
I am sure the people who make the backport will be willing to maintain the backport part of the code if needbe.

[quote=Brian Gladman;204934]Hi Guys,

If you are going to backport it to an earlier version of Python, could one of you decide who is going to maintain it as I won't be able to do this.

In fact my development version is python 3 and when python 2.7 is released not even 2.6 will work as I need something in 2.7 and 3.1 (ordered dictionaries).

Brian[/quote]
Maintenance is definitely an issue, or users will truly be locked into an early version.

Is there a manner to perform a "freeze" on the current code by a linux user and have that work under various linux distributions without having to have the current Python?

I wonder if I can build a conversion routine... I've never tried with something this involved.