Prev: Fake Prada Patent Leather Trunk Bag - White Fake HandBags
Next: Fake Triumph Mens Watch 3012-02
From: thomas.mertes on 11 Apr 2008 04:11
On 2 Apr., 20:27, Mensanator <mensana...(a)aol.com> wrote:
> On Apr 1, 5:54 am, thomas.mer...(a)gmx.at wrote:
> > On 31 Mrz., 06:38, Mensanator <mensana...(a)aol.com> wrote:
> > > On Mar 30, 6:02am, thomas.mer...(a)gmx.at wrote:
> > > > $ include "seed7_05.s7i";
>
> > > > const func integer: find_c (in array integer: sv) is func
> > > > result
> > > > var integer: c is 0;
> > > > local
> > > > var integer: i is 0;
> > > > begin
> > > > i := length(sv);
> > > > while sv[i] = 1 do
> > > > i -:= 1;
> > > > end while;
> > > > c := i;
> > > > end func;
>
> > > > const proc: main is func
> > > > local
> > > > var integer: depth is 0;
> > > > var integer: width is 0;
> > > > var integer: max_element is 0;
> > > > var array integer: sv is 0 times 0;
> > > > var integer: i is 0;
> > > > var integer: c is 0;
> > > > begin
> > > > #
> > > > # argv(PROGRAM) indices are {1,2,3...}
> > > > #
>
> > > > depth := integer parse (argv(PROGRAM)[1]);
> > > > width := integer parse (argv(PROGRAM)[2]);
> > > > max_element := depth - width + 1;
> > > > sv := width times 1;
>
> > > > if width <= depth then
> > > > sv[length(sv)] := max_element;
> > > > for i range sv do # print first partition
> > > > write(i);
> > > > write(" ");
> > > > end for;
> > > > writeln;
> > > > while sv[1] < max_element do
> > > > c := find_c(sv);
> > > > if c < length(sv) then
> > > > sv[c-1] +:= 1; # mov_col
> > > > sv[c] -:= 1;
> > > > sv[length(sv)] := sv[c];# rollover
> > > > sv[c] := 1;
> > > > for i range sv do # print partition
> > > > write(i);
> > > > write(" ");
> > > > end for;
> > > > writeln;
> > > > else
> > > > sv[c-1] +:= 1; # mov_col
> > > > sv[c] -:= 1;
> > > > for i range sv do # print partition
> > > > write(i);
> > > > write(" ");
> > > > end for;
> > > > writeln;
> > > > end if;
> > > > end while;
> > > > else
> > > > writeln("WIDTH MUST BE <= DEPTH . . . ABORTING");
> > > > end if;
> > > > end func;
> > When you tell me what operations your second example
> > uses (and how the code looks like) I can try to improve that
> > as well.
>
> It's the program above only with larger parameters.
>
> In this case, larger parameters only trivially increases
> the memory required. For parameters 6,4 I need an array
> of 4 integers. For parameters 26,14 I just need an array
> of 14 integers. But there are C(depth-1,width-1) partitions
> of depth items into width bins such that each bin has at
> least 1 item (6,4: 10 partitions; 26,14: 5200300 partitions).
>
> Thus, cpu intensive without being memory intensive or
> using Big Integers. That's where having a compiler has
> the advantage over a byte code interpreter.
>
> The actual test was about how I can call Seed7 programs
> from Python. It became memory intensive on the Python
> side because I was making a list of all the partitions
> and converting them to integers.
>
> Practically, I would probably write the partitions to
> a file for processing one at a time instead of trying
> to hold them all in memory.
>
> Of course, if you get decent speed out of your Big Integers,
> then maybe the processing can be done in Seed7 also. And I
> can still have Python scrape the results off StdOut if
> necessary. The first test had me considering dismissing
> Seed7, but this test has made me decide to hold onto it
> for awhile.
>
> I didn't do the processing as it was not relevant to the test.
> But it would consist of, for every partition,
>
> p = [2,1,4,1,1,2,1,1,1,3,1,2,5,1]
>
> dtermine the parameters of the function g = (Xa - Z)/Y where
>
> X = 2**sum(p)
> Y = 3**len(p)
> Z = 3**0*2**sum(p[:-1] + # sum of all except the last one
> 3**1*2**sum(p[:-2] + # sum of all except the last two
> 3**2*2**sum(p[:-3] + # sum of all except the last three
> .
> .
> .
> 3**(len(p)-3)*2**sum(p[:-(len(p)-2]) + # sum of first two
> 3**(len(p)-2)*2**sum(p[:-(len(p)-1)] + # sum of first one
> 3**(len(p)-1)*2**sum(p[:-len(p)] # sum of none (always 0)
>
> Which can get very messy and require Big Integers if the partition
> is large enough, so I didn't bother. Plus, once I have the parameters,
> I have to use linear congruence to solve for 'a' which is my I need
> modular inverse in my math library in addition to gcd.

I have not heard from you for some time. I am still
working on bigInteger's. I made it possible that the gmp
library is used for the bigInteger implementation of Seed7.
So there will be a choice, which library implements the
bigInteger functionality (gmp or the native Seed7 bigInteger
library). I made a thin wrapper library which interfaces between
gmp and the Seed7 bigInteger interfaces. Since this way both
libraries share the same interface there is no need to change
Seed7 programs. It will take approx. 10 days until I can release
this improvement as part of the next Seed7 release.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Mensanator on 11 Apr 2008 19:10
On Apr 11, 3:11 am, thomas.mer...(a)gmx.at wrote:
> On 2 Apr., 20:27, Mensanator <mensana...(a)aol.com> wrote:
>
>
>
>
>
> > On Apr 1, 5:54 am, thomas.mer...(a)gmx.at wrote:
> > > On 31 Mrz., 06:38, Mensanator <mensana...(a)aol.com> wrote:
> > > > On Mar 30, 6:02am, thomas.mer...(a)gmx.at wrote:
> > > > > $ include "seed7_05.s7i";
>
> > > > > const func integer: find_c (in array integer: sv) is func
> > > > > result
> > > > > var integer: c is 0;
> > > > > local
> > > > > var integer: i is 0;
> > > > > begin
> > > > > i := length(sv);
> > > > > while sv[i] = 1 do
> > > > > i -:= 1;
> > > > > end while;
> > > > > c := i;
> > > > > end func;
>
> > > > > const proc: main is func
> > > > > local
> > > > > var integer: depth is 0;
> > > > > var integer: width is 0;
> > > > > var integer: max_element is 0;
> > > > > var array integer: sv is 0 times 0;
> > > > > var integer: i is 0;
> > > > > var integer: c is 0;
> > > > > begin
> > > > > #
> > > > > # argv(PROGRAM) indices are {1,2,3...}
> > > > > #
>
> > > > > depth := integer parse (argv(PROGRAM)[1]);
> > > > > width := integer parse (argv(PROGRAM)[2]);
> > > > > max_element := depth - width + 1;
> > > > > sv := width times 1;
>
> > > > > if width <= depth then
> > > > > sv[length(sv)] := max_element;
> > > > > for i range sv do # print first partition
> > > > > write(i);
> > > > > write(" ");
> > > > > end for;
> > > > > writeln;
> > > > > while sv[1] < max_element do
> > > > > c := find_c(sv);
> > > > > if c < length(sv) then
> > > > > sv[c-1] +:= 1; # mov_col
> > > > > sv[c] -:= 1;
> > > > > sv[length(sv)] := sv[c];# rollover
> > > > > sv[c] := 1;
> > > > > for i range sv do # print partition
> > > > > write(i);
> > > > > write(" ");
> > > > > end for;
> > > > > writeln;
> > > > > else
> > > > > sv[c-1] +:= 1; # mov_col
> > > > > sv[c] -:= 1;
> > > > > for i range sv do # print partition
> > > > > write(i);
> > > > > write(" ");
> > > > > end for;
> > > > > writeln;
> > > > > end if;
> > > > > end while;
> > > > > else
> > > > > writeln("WIDTH MUST BE <= DEPTH . . . ABORTING");
> > > > > end if;
> > > > > end func;
> > > When you tell me what operations your second example
> > > uses (and how the code looks like) I can try to improve that
> > > as well.
>
> > It's the program above only with larger parameters.
>
> > In this case, larger parameters only trivially increases
> > the memory required. For parameters 6,4 I need an array
> > of 4 integers. For parameters 26,14 I just need an array
> > of 14 integers. But there are C(depth-1,width-1) partitions
> > of depth items into width bins such that each bin has at
> > least 1 item (6,4: 10 partitions; 26,14: 5200300 partitions).
>
> > Thus, cpu intensive without being memory intensive or
> > using Big Integers. That's where having a compiler has
> > the advantage over a byte code interpreter.
>
> > The actual test was about how I can call Seed7 programs
> > from Python. It became memory intensive on the Python
> > side because I was making a list of all the partitions
> > and converting them to integers.
>
> > Practically, I would probably write the partitions to
> > a file for processing one at a time instead of trying
> > to hold them all in memory.
>
> > Of course, if you get decent speed out of your Big Integers,
> > then maybe the processing can be done in Seed7 also. And I
> > can still have Python scrape the results off StdOut if
> > necessary. The first test had me considering dismissing
> > Seed7, but this test has made me decide to hold onto it
> > for awhile.
>
> > I didn't do the processing as it was not relevant to the test.
> > But it would consist of, for every partition,
>
> > p = [2,1,4,1,1,2,1,1,1,3,1,2,5,1]
>
> > dtermine the parameters of the function g = (Xa - Z)/Y where
>
> > X = 2**sum(p)
> > Y = 3**len(p)
> > Z = 3**0*2**sum(p[:-1] + # sum of all except the last one
> > 3**1*2**sum(p[:-2] + # sum of all except the last two
> > 3**2*2**sum(p[:-3] + # sum of all except the last three
> > .
> > .
> > .
> > 3**(len(p)-3)*2**sum(p[:-(len(p)-2]) + # sum of first two
> > 3**(len(p)-2)*2**sum(p[:-(len(p)-1)] + # sum of first one
> > 3**(len(p)-1)*2**sum(p[:-len(p)] # sum of none (always 0)
>
> > Which can get very messy and require Big Integers if the partition
> > is large enough, so I didn't bother. Plus, once I have the parameters,
> > I have to use linear congruence to solve for 'a' which is my I need
> > modular inverse in my math library in addition to gcd.
>
> I have not heard from you for some time. I am still
> working on bigInteger's. I made it possible that the gmp
> library is used for the bigInteger implementation of Seed7.
> So there will be a choice, which library implements the
> bigInteger functionality (gmp or the native Seed7 bigInteger
> library). I made a thin wrapper library which interfaces between
> gmp and the Seed7 bigInteger interfaces. Since this way both
> libraries share the same interface there is no need to change
> Seed7 programs. It will take approx. 10 days until I can release
> this improvement as part of the next Seed7 release.

That sounds very interesting.

You're making it harder and harder for me to dismiss Seed7. :-)

I never converted the attractor locator (minimum values in the
loop cycles of 3n+C) from C because, as pointed out, it's not
necessary to save all the sequence values in order to find
where a sequence repeats. My C program does that now and I'm
stuck trying to find the cycle length of a special number (a
power_of_two - 3 that happens to be prime) that I suspect has
a record-setting loop cycle length (which is why it's killing
my C program).

My goal is not simply evaluating languages, but trying to do
some research. I'm still trying to verify certain properties
of 3n+C. In previous searches for long loop cycles, I had
observed a tendency for long cycles to occur when C is prime
while the initial seed is 1. But the special numbers have a
certain property that caused them to be overlooked previously.
Although they generate long loop cycles, the special property
is that the seed 1 ALWAYS produces a loop cycle of length 1,
so you need some way of getting out of that cycle and into one
of the long ones and see if it is a record-setter. I REALLY
need the attractor locator to work with these special numbers.

My C program currently crashes (out of memory) with this
number. The same would surely happen if I used the same algorithm
in Seed7.

So I'm looking at new algorithms. On Wikipedia, I found Floyd's
algorithm and Brent's algorithm for cycle detection with examples
in Python! They worked great without using up the memory, but the
tradeoff is cpu time. The Python version of Brent's algorithm was
still running after 8 hours. I even tried Brent's algorithm in
compiled Seed7 which worked, but was still taking too much time
even with numbers much smaller than the special number I'm trying
to solve.

So, a little more web search and I found an implementaion of
Sedgewick's Cycle Detection Algorithm which allows you to set up
something like Brent with a finite amount of memory. Alas, it's
in C. So, after a lot of wailing and gnashing of teeth trying to
get it to compile, I finally got it working.

Somewhat.

Getting a segment fault on the special number, sounds like
something doesn't realize the array is finite. I had to do a lot
of substituting long long for long to get it to work at all and
finally squeezed out a result prior to the segment fault (the
fact that the entry point of the loop sequence was shown as a
negative number was the overflow giveaway.)

Luckily, that attractor turned out to be correct which I was
trivially able verify in Python.

And wow, it's a record all right! Starting at 167 with
3n+536870909, the loop cycle has 19,883,729 elements (and
that just counts the odds, there would be twice as many evens).
And there could be other, equal or longer loop cycles (once I
figure out the segment faults).

Damn, that is one nasty problem. But then, I wouldn't be
considering Seed7 if everything was easy.

I'm pondering what to do next. Since the main algorithm is
already in C, it would smartest to keep it there. But I'm
segment faulting and overflowing, so I at least have to add
GMP to it as long long is insufficient. And I'm not looking
forwards to that as I'm not much of a C programmer.

Or I could try to implement Sedgewick's algorithm in Seed7
and see how that goes.

I don't know which will be easier. I'll probably try Seed7
and if it ends up too slow even with Sedgewick, I can try it
again when you release Seed7+GMP.

I'll post something if I can get it to work.

>
> Greetings Thomas Mertes
>
> Seed7 Homepage: http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.


From: thomas.mertes on 13 Apr 2008 15:05
On 12 Apr., 01:10, Mensanator <mensana...(a)aol.com> wrote:
> On Apr 11, 3:11 am, thomas.mer...(a)gmx.at wrote:
>
>
>
> > On 2 Apr., 20:27, Mensanator <mensana...(a)aol.com> wrote:
>
> > > On Apr 1, 5:54 am, thomas.mer...(a)gmx.at wrote:
> > > > On 31 Mrz., 06:38, Mensanator <mensana...(a)aol.com> wrote:
> > > > > On Mar 30, 6:02am, thomas.mer...(a)gmx.at wrote:
> > > > > > $ include "seed7_05.s7i";
>
> > > > > > const func integer: find_c (in array integer: sv) is func
> > > > > > result
> > > > > > var integer: c is 0;
> > > > > > local
> > > > > > var integer: i is 0;
> > > > > > begin
> > > > > > i := length(sv);
> > > > > > while sv[i] = 1 do
> > > > > > i -:= 1;
> > > > > > end while;
> > > > > > c := i;
> > > > > > end func;
>
> > > > > > const proc: main is func
> > > > > > local
> > > > > > var integer: depth is 0;
> > > > > > var integer: width is 0;
> > > > > > var integer: max_element is 0;
> > > > > > var array integer: sv is 0 times 0;
> > > > > > var integer: i is 0;
> > > > > > var integer: c is 0;
> > > > > > begin
> > > > > > #
> > > > > > # argv(PROGRAM) indices are {1,2,3...}
> > > > > > #
>
> > > > > > depth := integer parse (argv(PROGRAM)[1]);
> > > > > > width := integer parse (argv(PROGRAM)[2]);
> > > > > > max_element := depth - width + 1;
> > > > > > sv := width times 1;
>
> > > > > > if width <= depth then
> > > > > > sv[length(sv)] := max_element;
> > > > > > for i range sv do # print first partition
> > > > > > write(i);
> > > > > > write(" ");
> > > > > > end for;
> > > > > > writeln;
> > > > > > while sv[1] < max_element do
> > > > > > c := find_c(sv);
> > > > > > if c < length(sv) then
> > > > > > sv[c-1] +:= 1; # mov_col
> > > > > > sv[c] -:= 1;
> > > > > > sv[length(sv)] := sv[c];# rollover
> > > > > > sv[c] := 1;
> > > > > > for i range sv do # print partition
> > > > > > write(i);
> > > > > > write(" ");
> > > > > > end for;
> > > > > > writeln;
> > > > > > else
> > > > > > sv[c-1] +:= 1; # mov_col
> > > > > > sv[c] -:= 1;
> > > > > > for i range sv do # print partition
> > > > > > write(i);
> > > > > > write(" ");
> > > > > > end for;
> > > > > > writeln;
> > > > > > end if;
> > > > > > end while;
> > > > > > else
> > > > > > writeln("WIDTH MUST BE <= DEPTH . . . ABORTING");
> > > > > > end if;
> > > > > > end func;
> > > > When you tell me what operations your second example
> > > > uses (and how the code looks like) I can try to improve that
> > > > as well.
>
> > > It's the program above only with larger parameters.
>
> > > In this case, larger parameters only trivially increases
> > > the memory required. For parameters 6,4 I need an array
> > > of 4 integers. For parameters 26,14 I just need an array
> > > of 14 integers. But there are C(depth-1,width-1) partitions
> > > of depth items into width bins such that each bin has at
> > > least 1 item (6,4: 10 partitions; 26,14: 5200300 partitions).
>
> > > Thus, cpu intensive without being memory intensive or
> > > using Big Integers. That's where having a compiler has
> > > the advantage over a byte code interpreter.
>
> > > The actual test was about how I can call Seed7 programs
> > > from Python. It became memory intensive on the Python
> > > side because I was making a list of all the partitions
> > > and converting them to integers.
>
> > > Practically, I would probably write the partitions to
> > > a file for processing one at a time instead of trying
> > > to hold them all in memory.
>
> > > Of course, if you get decent speed out of your Big Integers,
> > > then maybe the processing can be done in Seed7 also. And I
> > > can still have Python scrape the results off StdOut if
> > > necessary. The first test had me considering dismissing
> > > Seed7, but this test has made me decide to hold onto it
> > > for awhile.
>
> > > I didn't do the processing as it was not relevant to the test.
> > > But it would consist of, for every partition,
>
> > > p = [2,1,4,1,1,2,1,1,1,3,1,2,5,1]
>
> > > dtermine the parameters of the function g = (Xa - Z)/Y where
>
> > > X = 2**sum(p)
> > > Y = 3**len(p)
> > > Z = 3**0*2**sum(p[:-1] + # sum of all except the last one
> > > 3**1*2**sum(p[:-2] + # sum of all except the last two
> > > 3**2*2**sum(p[:-3] + # sum of all except the last three
> > > .
> > > .
> > > .
> > > 3**(len(p)-3)*2**sum(p[:-(len(p)-2]) + # sum of first two
> > > 3**(len(p)-2)*2**sum(p[:-(len(p)-1)] + # sum of first one
> > > 3**(len(p)-1)*2**sum(p[:-len(p)] # sum of none (always 0)
>
> > > Which can get very messy and require Big Integers if the partition
> > > is large enough, so I didn't bother. Plus, once I have the parameters,
> > > I have to use linear congruence to solve for 'a' which is my I need
> > > modular inverse in my math library in addition to gcd.
>
> > I have not heard from you for some time. I am still
> > working on bigInteger's. I made it possible that the gmp
> > library is used for the bigInteger implementation of Seed7.
> > So there will be a choice, which library implements the
> > bigInteger functionality (gmp or the native Seed7 bigInteger
> > library). I made a thin wrapper library which interfaces between
> > gmp and the Seed7 bigInteger interfaces. Since this way both
> > libraries share the same interface there is no need to change
> > Seed7 programs. It will take approx. 10 days until I can release
> > this improvement as part of the next Seed7 release.
>
> That sounds very interesting.
>
> You're making it harder and harder for me to dismiss Seed7. :-)

Hopefully it is harder for others also. :-)

> I never converted the attractor locator (minimum values in the
> loop cycles of 3n+C) from C because, as pointed out, it's not
> necessary to save all the sequence values in order to find
> where a sequence repeats. My C program does that now and I'm
> stuck trying to find the cycle length of a special number (a
> power_of_two - 3 that happens to be prime) that I suspect has
> a record-setting loop cycle length (which is why it's killing
> my C program).

If you provide me with the C program I might be able to do
some tests with the Seed7 version of this algorithm.

> My goal is not simply evaluating languages, but trying to do
> some research.

My motivation is different from yours, but there is enough
overlap to serve both goals. My goal is not doing some mathematic
research, but to improve Seed7 (which has to do with research in
computer science). I want Seed7 to be usable for practical problems.
When you try to solve some problem you might discover missing
functionality or missing performance in Seed7. This is valuable
information for me. I used your program for the Collatz Conjecture
as benchmark. I also use a program to compute the 5200300
partitions (26,14) and the values of X, Y and Z as testcase.
This program needs also the improvements/bugfixes which will be
part of the next release. With the current release you would not
get satisfying results (this has not to with gmp). Since you
mentioned it, I looked at the modular inverse function. I am not
sure if a pure Seed7 version of modular inverse delivers enough
performance or the mpz_invert function form gmp is needed. In this
case I need to implement an bigInvert function for my bigInteger
library as well, since Seed7 should be usable without gmp also.
If you need some other mpz_ please tell me as well.

> I'm still trying to verify certain properties
> of 3n+C. In previous searches for long loop cycles, I had
> observed a tendency for long cycles to occur when C is prime
> while the initial seed is 1. But the special numbers have a
> certain property that caused them to be overlooked previously.
> Although they generate long loop cycles, the special property
> is that the seed 1 ALWAYS produces a loop cycle of length 1,
> so you need some way of getting out of that cycle and into one
> of the long ones and see if it is a record-setter. I REALLY
> need the attractor locator to work with these special numbers.
>
> My C program currently crashes (out of memory) with this
> number. The same would surely happen if I used the same algorithm
> in Seed7.

When a C program is out of (virtual) memory a Seed7 program would
probably also be out of (virtual) memory. Normally programs slow
down when they use more and more memory (thrashing). When the C
program crashes for other reasons Seed7 could provide an advantage
since the memory is managed automatically (without garbage
collection) and several other things (eg. array element access)
are checked for RANGE_EXCEPTIONs.

> So I'm looking at new algorithms. On Wikipedia, I found Floyd's
> algorithm and Brent's algorithm for cycle detection with examples
> in Python! They worked great without using up the memory, but the
> tradeoff is cpu time. The Python version of Brent's algorithm was
> still running after 8 hours. I even tried Brent's algorithm in
> compiled Seed7 which worked, but was still taking too much time
> even with numbers much smaller than the special number I'm trying
> to solve.

Can you provide me with this program? Maybe I can do some
performace analysis with a profiler (I am able to profile compiled
Seed7 programs).

> So, a little more web search and I found an implementaion of
> Sedgewick's Cycle Detection Algorithm which allows you to set up
> something like Brent with a finite amount of memory. Alas, it's
> in C. So, after a lot of wailing and gnashing of teeth trying to
> get it to compile, I finally got it working.
>
> Somewhat.
>
> Getting a segment fault on the special number, sounds like
> something doesn't realize the array is finite.

C does not check for the end of an array (Seed7 does).

> I had to do a lot
> of substituting long long for long to get it to work at all and
> finally squeezed out a result prior to the segment fault (the
> fact that the entry point of the loop sequence was shown as a
> negative number was the overflow giveaway.)
>
> Luckily, that attractor turned out to be correct which I was
> trivially able verify in Python.
>
> And wow, it's a record all right! Starting at 167 with
> 3n+536870909, the loop cycle has 19,883,729 elements (and
> that just counts the odds, there would be twice as many evens).
> And there could be other, equal or longer loop cycles (once I
> figure out the segment faults).
>
> Damn, that is one nasty problem. But then, I wouldn't be
> considering Seed7 if everything was easy.
>
> I'm pondering what to do next. Since the main algorithm is
> already in C, it would smartest to keep it there. But I'm
> segment faulting and overflowing, so I at least have to add
> GMP to it as long long is insufficient. And I'm not looking
> forwards to that as I'm not much of a C programmer.
>
> Or I could try to implement Sedgewick's algorithm in Seed7
> and see how that goes.
>
> I don't know which will be easier. I'll probably try Seed7
> and if it ends up too slow even with Sedgewick, I can try it
> again when you release Seed7+GMP.

To make it clear: Not all of the GMP (mpz_...) functions will be
available in the next Seed7 release. I use the GMP library as an
alternate implementation of the Seed7 bigInteger library that
already exists. When you need additional GMP (mpz_...) functions
tell me about them. I will try to provide them (which means that
I have to implement them also in the current Seed7 bigInteger
library).

> I'll post something if I can get it to work.

I look forward for new food for thought.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
From: Mensanator on 15 Apr 2008 00:51
Ok, first version (ccd011.c) is uploaded at

<http://members.aol.com/mensanator/cycle/ccd011.c>

Seems I forgot to mention where this originated:

<http://www.cs.umbc.edu/~hosu/algorithm/tr.html>

Still having compiler problems, but looks like my
laptop can do the GMP linking, so it all looks
doable.
From: Mensanator on 18 Apr 2008 00:47
On Apr 17, 1:44�pm, Mensanator <mensana...(a)aol.com> wrote:
> Sure, I'll put a copy on my website, same place as the Sedgewick
> algorithm. I'll have to do that later when I have access to my
> website. I'll post a note here when it's there. To be fair,
> I didn't give it a 9-hour test like I did the Python version, but
> it was taking much more time than I had patience for.

Ok, the Seed7 implementaion of Brent's algorithm
(I didn't do Floyd's as the Python test seemed to
show that Brent's was better for this application)
is now on my website:

<http://members.aol.com/mensanator/cycle/ecd.sd7>

The first part of the file is a huge comment showing
the original Python code plus some test results. The
actual Seed7 code follows.

Here's one of my test results using compiled Seed7:
(the 3 parameters are Start, End, C).

mensanator(a)DEEPESTTHOUGHT ~/gmp-4.1.2/seed7
$ ./ecd 1 2714 2097149

1
331
361
373
481
533
673
703
929
23963
70343
84103
2097149

time 5:00

Altough this used virtually no memory, look at the
time compared to my memory intensive C version:

mensanator(a)DEEPESTTHOUGHT ~/gmp-4.1.2
$ ./attractors023 1 2714 2097149 0
Attractors (initiators) loop_gcd
1 (1) 1
331 (41) 1
361 (13) 1
373 (59) 1
481 (29) 1
533 (11) 1
673 (3) 1
703 (5) 1
929 (25) 1
23963 (2319) 773
70343 (773) 773
84103 (2713) 2713
2097149 (2097149) 2097149

time 0:03.87

So we're losing the memory/cpu tradeoff.

When I kick C up to a value that's intrabable memory-wise,

$ ./attractors023.exe 1 5000 536870909 1
Sequence Vector:
[29]

Error:Out of memory

It becomes way too slow using Brent's algorithm. Exactly how
slow I don't know, I never let it finish. The Python version
was still running after 9 hours.

I'm hoping that with Sedgewick's algorithm and a couple
hundred megs of fixed RAM, I can get a tractable run-time
in C.

Then we can see how it fares in Seed7 (if we can figure out
how to do that goofy C algorithm in Seed7).

That number, 536870909, is a power of two minus 3 that's
prime, which seem particularly well suited to producing
extremely long loop cycles (it has at least one cycle of
19 million odd numbers). Speciffically, 2**29-3. The next
such prime is 2**94-3, so this may be the limit.
 |  Next  |  Last
Pages: 1 2 3
Prev: Fake Prada Patent Leather Trunk Bag - White Fake HandBags
Next: Fake Triumph Mens Watch 3012-02