Read Mail


From: "Mircea Pasoi" <mircea_pasoi@hotmail.com> [Save Address] [Block Sender]
To: mircea@mindless.com
Cc:
Subject: Fwd: Fw: final results
Date: Fri, 31 May 2002 23:18:45 +0300



Reply | Reply All | Forward Previous | Next
  

>From: "Crestez Leonard" <http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=cleonard%40go.ro>
>To: <http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=mircea_pasoi%40hotmail.com>
>Subject: Fw: final results
>Date: Fri, 31 May 2002 10:10:59 +0300
>
>
>----- Original Message -----
>From: Stefan Ciobaca
>To: Alex Litu ; Andrei Gabriel Stanescu ; Andrei Markovits ; Andrei
Matei ; 
>Andrei Zattuu ; balangh ; Bartha Zsolt ; Bogdan Panus ; Bza ; chiri
bogdan 
>; Computer Libris Agora ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=lucianxxx%40post.ro ; Crestez Leonard ; 
>http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=cleonard%40go.ro ; Cy Q ; Dinu Razvan ; Dumitrache Alexandru ; fechete
stefan 
>; Fedsg (FPT) ; Fritz ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=aurelianghita%40xnet.ro ; Horia Andrei
Ciochina ; 
>Jozef Tvarozek ; Mugurel Ionut Andreica ; Ovidiu Sabou ;
http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=lucianxxx%40post.ro 
>; Paul Rusu ; Popovici Dan ; Razvan Tigaeru ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=lucianxxx%40post.ro ;
Scythe ; 
>SIA ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=ioli%40xnet.ro ; Sorin Balasioiu ; Stefan Ciobaca ; The t3as3r ;
Tibi 
>D. ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=ioli%40xnet.ro ; Victor Costan ; X Xx ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=aurelianghita%40xnet.ro ;
zemba 
>albert ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=ioli%40xnet.ro ; Danny G ; Dan Savu ; Costan Victor ; Andrei
Giurgiu 
>; Leviathan ; http://mail01.mail.com/scripts/mail/Outblaze.mail?compose&mircea:mindless.com&a&&composeto=ioli%40xnet.ro
>Sent: Thursday, April 25, 2002 2:03 AM
>Subject: final results
>
>
>final results are attached.
>also test data for every problem is attached.
>
>--------------
>Stefan Ciobaca
>
>




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


Alice

Decrease

FarmerJ

Amax

Company

Figures

Points

Sum

Path

Rland

Days

Total

1

Mugurel Ionut Andreica

100

100

100

90

100*

100*

100*

100*

100*

100*

100*

1090

2

Berinde Radu

100

60

100

40

100

100

100

100

100

100

100

1000

3

Stefan Ciobaca

-

100

100*

-

100

100

100

100

100

66

100

866

4

Tiberiu Danet

100

40

100

10

95

40

100

100

20

80

80

765

5

Andrei Giurgiu

100

-

-

-

100

100

100

100?

100

60

-

660

6

Alex Dumitrache

-

-

100

-

95

100

50

100

90

!

100

635

7

Victor Costan

-

100

-

100

100

0

100

0

100

100

10

610

8

Savu Dan

0

60

-

!

25

82.5

100

100

55.5

12

100

535

9

Fechete Stefanita

-

10

100

100*

25

3

30

100

30

64

30

492

10

Jozef Tvarozek

100

-

-

-

25

47.5

70

100

-

90

-

432.5

11

Popovici Dan

100*

100*

-

-

-

-

-

-

!

-

90

290

12

Ghinea Dan

-

80

-

!

-

100

100

10

-

-

-

290

13

Markovits Andrei

-

-

-

-

55

30

-

10

100

64

30

289

14

Iolanda Popa

-

100

!

0

95

-

0

-

-

-

-

195

15

Stanciu Lucian Daniel

-

20

-

0

0

33.5

70

40

-

0

20

183.5

16

Chiri Bogdan

-

20

-

-

-

-

100

50

5

-

-

175

17

Razvan Tigaeru

0

50

-

-

-

-

-

10

-

!

0

60

18

Crestez Leonard

-

-

-

-

-

-

0

-

-

30

-

30

19

Ovidiu Sabou

-

-

-

-

-

-

30

-

-

-

-

30

20

Bartha Zsolt

-

20

-

-

-

-

0

-

5

-

0

5

In this table only the contestants that sent me their source codes were accounted for.

- means that the contestant either didn’t send source code for that problem or there was a compilation error

! means that the problem crashed my computer

* means that the task was proposed by that person

There was a problem with task Decrease. Test 7 required big numbers, so I skipped that test and everyone who sent their source code for that problem got 10p extra. The reason I didn’t want big numbers was because you loose focus on the algorithm. This task is a very cool task (at least I thought so when I first saw it) and it isn’t about big numbers, but about big thinking ;-)

The speed guru of the contest is Victor Costan. He managed to solve all the 10 test data for the problem AMAX in under 5 seconds. I would like for him to explain his solution, that is of course if he also wants to.

Victor also won another title: the mistake maker. He had a compilation error in alice.c (he used a non-standard math function). He outputted garbage on screen in task Figures and all of the tests timed out because of the slowdown involved.  Also, he thought the input and output file for task Sum were suma.in and suma.out instead of sum.in and sum.out. This also cost him 100 points. Victor shares this title with Dan Popovici, who wrote C++ and gcc, which I can’t compile together (as I mentioned a couple of times), so he got „-”, instead of many points.

The price for the most curious person goes to Scythe (Berinde Radu), who must have sent me about 2 tons of email with observations and questions about the tasks.

Next I will present the solutions to some of the tasks (for amax the solution will be posted tomorrow --- hopefully Victor will tell us about his speedy solution).

Sorry for international users, the solutions to follow are Romanian:

### COMPANIA ###

Complexitate: O(E*E*ln(E))

Programare dinamica

P[i] = numarul minim de persoane necesare pt. a obtine eficienta i

S[i] = numarul minim de sefi necesari pt. a obtine eficienta i

            La adaugarea unui grup de i persoane, avand j sefi, eficienta

creste cu (i-j)*j. Se adauga la toate eficientele ce s-au obtinut anterior

(un fel rucsac).

*** comentariul meu: solutia mea este de complexitate E^2.

### FIGURI ###

Complexitate: O(N^2)

Memorie: 8*N^2 bytes

            Pt. patrat: solutie clasica in O(N^2).

            Pt. romb: se imparte rombul in 8 figuri elementare:

- 4 triunghiuri dreptunghice, cu varfurile langa centru rombului

(bucatile din exteriorul crucii din centru)

- 4 fasii orientate spre N,E,S,V (ce formeaza crucea din centru)

            Se poate determina in O(N^2) pt. fiecare tip de figura, care

este aria maxima a unei astfel de figuri cu varful/capatul la coordonatele

(i,j). Apoi se incearca fiecare pozitie din matrice drept centru al unui

romb si folosind valorile calculate pt. fiecare tip de figura, se determina

latura maxima a unui romb centrat in (i,j).

*** comentariul meu: aici Mugurel a gresit evident ;-)

nu era nevoie de 8 matrici (sa fim seriosi) ci numai de doua. Complexitatea ramane aceeasi, dar memoria scade dramatic.

Solutia miraculoasa se bazeaza pe o „formula de recurenta pentru romburi”. Mai exact:

0 0 1 0 0

0 1 1 1 0

1 1 1 1 1

0 1 1 1 0

0 0 1 0 0

Rombul acesta este alcatuit din:

0 0 2 0 0 (un romb mai mic mai sus)

0 2 2 2 0

1 1 2 1 1

0 1 1 1 0

0 0 1 0 0

0 0 1 0 0 (un romb mai mic mai la stanga)

0 3 1 1 0

3 3 3 1 1

0 3 1 1 0

0 0 1 0 0

0 0 1 0 0 (un romb mai mic mai la dreapta)

0 1 1 4 0

1 1 4 4 4

0 1 1 4 0

0 0 1 0 0

si

0 0 1 0 0 (doua casute pline)

0 1 1 1 0

1 1 1 1 1

0 1 6 1 0

0 0 6 0 0

astfel, intr-o matrice l[i][j] retineam lungimea maxima a unui romb care are vf de jos pe linia i si coloana j

matricea se completa de sus in jos de la stanga la dreapta cu o formula de recurenta banala

### PUNCTE ###

Complexitate: O(1)

Raspuns: Combinari de N luate cate 4

Oricare 4 puncte ale poligonului definesc EXACT un punct de intersectie

(prin cele 2 diagonale care se intersecteaza)

### SUMA ###

Complexitate: O(N)

Programare dinamica (s-ar putea numi astfel)

SUM[1] = suma maxima ce se poate obtine folosind elementul curent si

neavand elemente de pe pozitii consecutive alaturate

SUM[0] = suma maxima ce se poate obtine FARA elementul curent

Cele 2 valori se calculeaza in O(1) din valorile anterioare (uita-te in

sursa mea pt. a vedea cum anume)

*** comentariul meu: aici am facut altfel, mai babeste si ce-i drept mai naspa. In loc sa folosesc formula de mai sus cu C de n luate cate 4, am folosit o formula descoperita de mine numarand punctele de intersectie. Mergea pentru n = 5, 6, 7 ===(prin inductie programatorica ;-))==> merge pentru orice n. Mai exact, formula mea era cam asa: daca s(i) = 1 + 2 + ... + i, t(i) = s(1) + s(2) + ... + s(i), u(i) = t(1) + t(2) + ... + t(i), atunci numarul cautat este u(n - 3) parca.

### TEREN ###

Complexitate: O(N^3)

            Se calculeaza sume partiale: S[i,j] = suma elementelor de pe

linia i, de pe coloanele 1..j. Aceasta matrice se determina in O(N^2).

Folosind aceasta matrice, se determina in O(N^2) solutia pentru primul

tip de dreptunghi. Se determina apoi dreptunghiul de suma maxima

cu 1 linie si Q coloane,2 linii,.., P linii. Pt. fiecare numar de

linii, complexitatea este O(N^2) => P*O(N^2) aprox. O(N^3)

*** comentariul meu (sau cum se pierd 44 puncte): incerci sa rezolvi problema in N^2 cand stii foarte bine ca 150^3 merge lejer. Totusi rezolvi in N^2, dar gresesti la implementare ===== > - 44 puncte ;-)

### TRASEU ###

Complexitate: O(N^3)

            Lungimea minima se determina cu un BF din orasul i.

Numarul de trasee se deterimna folosind PD si calculand

matricea C[a,b] = numarul de trasee de la orasul i la orasul a,

de lungime b. Numarul cautat este C[1,distminima(i,1)]*C[j,distminima(i,j)].

            Folosind matricea de mai sus, se face apoi un backtracking care merge

direct spre solutie.

*** no comment ;-)

### ZILE ###

Complexitate: O(N^4)

Programare dinamica

A[i,j] = 0 sau 1, daca se pot obtine i perechi folosind in total j persoane.

            Se adauga cate un grup de i persoane nascute in aceeasi zi, iar numarul

            perecjilor creste cu i*(i-1)/2. Trebuie avuta grija sa nu se adauge

            mai mult de Z (in varianta in engleza: D) grupuri

*** la fel no comment

### Farmer John ###

Problema este inspirata de la USACO – Canada Tour. Belea problema nu? Asta pana cand te prinzi de rezolvare. Atunci o gasesti ca fiind o problema foarte cool. Rezolvarea se bazeaza pe programare dinamica.

A[i][j] – numarul maxim de litere folosite astfel incat ultimile litere folosite sa fie a Ia si a Ja.

Tabloul se poate calcula in timp N^3 folosind o programare dinamica recursiva.

### Decrease ###

Problema a fost si ea propusa la USACO candva. Se chema Buy Low, Buy Lower. Ideea de rezolvare este printre cele mai dragute din cate exista. Iata un text sterpelit de pe la USACO despre ea:

PROBLEM 2: Buy Low, Buy Lower

This is really a very nice problem. It involves a little thinking if you know what you're doing, and a lot if you don't. It will, unfortunately, take a while to explain starting from scratch, the way I'd like to. Get comfortable, but don't--please don't--just skip on down to the code. If you do that, you'll miss the subtleties that make the problem so great. Go ahead and try to figure things out for yourself, but at least give at least a cursory glance to what I've got to say. Even if you think you found a pretty good way. If the words "linear time" don't mean anything to you, you could have done a better job.

To start, let's look at a so-called bad solution. It is easy to right, but horribly, horribly exponential-time slow. It is, of course, the brute-force try-every-possibility recursive method. For the sake of argument, though, I'm going to look at it anyway. At the first level of recursion, we can either buy or not buy. Simple enough. If we don't buy, then the second day works the same way. If we do buy on the first day, then we also have to compare the costs to make sure that that of the second day is less than that of the first day. This method is still not too complicated.

But you pay a price. Let's say that, instead of three days, you have to look at thirty. Now, you still have the same choices to make for the first and second days, but look at it this way (assume that the cost of day 2 is less than that of day one): if you buy on the second day, you will have the same exact combinations going on further down the line no matter what you did on the first day, but you will have to count them twice anyway. True, you could throw together some sort of optimization to prevent this, but that would be too much trouble (and, knowing the better way, just thinking about it makes my head hurt). You're better off saving the optimization for the optimization problems. How do you know what is an optimization problem and what isn't? Well, that's the hard part.

So what kind of a problem is this one, if it isn't optimization? Another Dynamic Programming one, of course. Regular readers should have seen it coming up a paragraph ago, if not sooner. If you ever have recursion going on, always, always look for a DP solution instead. Sometimes there is one and sometimes there isn't but it's always worth a look. Especially when you've got a one- dimensional list of numbers to process. Ninety percent of the time, those are DP.

Before I get to anything too detailed, I'm going to outline exactly what the DP'll do. Notice that every single series of purchases you can possibly make has a last day on which you buy. (There are no infinite series.) Take some series for some given set of prices. If, after the series's last day, there are no more days with lower prices, then we are done. That series is already as long as we can make it. On the other hand, if there are other days with prices lower than the last of the series, then they can be added and there is a better (longer) series. Now we have a slight dilemma: which one do we add, if there's more than one possibility? The only answer at this point is to try them all (recursively) and pick the best.

We've already decided that recursion is for this problem a Bad Thing, so let's try looking at it from the other end. Instead of being given a series which may or may not want something tacked on to its end, we're just given a single element which we know desparately wants to be tacked on to the end of another series. And not just any series--it'll only accept the best. It's even taken out Personals ads in the newspaper. Despite all of this effort, it's decision is easier than that of the series. It doesn't care what might come after it; that's the problem of all of those other elements. All it has to do is pick the series which is the longest out of all the ones that came before it. How does it know where the longest is? Well, it asks all of its little element buddies from earlier in the month how long a series they were able to hop onto the end of. Then, it takes the longest of those answers (among those which it is smaller than, of course--it's gotta have that aerodynamic look once they all chain together) and adds itself to the end.

This heart-rending scenario should make clear what the DP solution does. It iterates through each element in the array. For the first, it remembers that the maximum length series it can make ending on that element is of length one. (There is just no other choice--a series of only itself is alwasys possible.) For each other element, it iterates through all of the elements that have come before it. By default, each has a maximum preceding length of zero. If any given predecessor has both a lower price and a better maximum length, then it becomes the new maximum preceding length. Once they've all been checked, the element's maximum length (the length of the longest series ending on it) is set to the maximum preceding length plus one. That's it. The answer--the length of the longest series--is simply the greatest of these maximum-ending-on-me lengths.

My finely-honed telepathic powers sense something amiss. "John must be losing it," I can hear you thinking. "Not only is he pretending that tiny bits of inanimate memory are really people with feelings, motivations, and desires, but he's left off half the problem. What about the number of ways to get a series this long? I would of done it exactly the way you described it, but there's no way that DP can find the number of ways." Well, as much as I hate to say it, you're wrong on all counts. I just wanted to simplify the problem while I introduced the DP solution, that's all. And anthropomorphism is a legitimate literary technique. Really.

Now that we're going to get a little more complex, I'll go into greater detail about the algorithm. The body of the algorithm is contained in a for loop iterating a variable (call it i) from 1 to N, the number of total days. For each i, there is also another for loop on j, going from 1 to i-1. For each preceding element (called data[j]), there can be three possible actions taken. If data[j] < data[i] or best[j]+1 < best[i], then we know that we can't do anything at all because the price went up between these two days or we found a shorter series than what we already had. Call this case A. If best[j]+1 > best[i], then we must set best[i] to best[j]+1. This means that a longer series has been found; call it case B. Finally, what do we do if best[j]+1 == best[i], that is we would get a series of the same length? Nothing at all yet (because we already know that the series could be that long), but we'll call it case C anyway. Everything else we've looked at so far has been put into its proper place now.

Let's look at the number of ways now. There really is no intuitive way that I can find to explain all of what I'm going to do; I just made a series of guesses at what might work until I found something that looked like it should. To start with, let's say that some form of DP should work, just because it seems like it should and I say it should. We'll do something that fits in with the best array I just worked out in such great detail: there will be a new array, appropriately named ways, in which ways[i] stores the number of different ways to make a series of length best[i] ending with the i-th day. We know that there is only one series at all ending on the first day; that will be our base case.

Now, imagine all of the different cases which could influence the number of ways to produce a series of a given length and ending on a given day. Obviously, we know the last cost of the series, so the number of different ways from any one pre-existing series is equal to the number of ways to make that pre-existing series. Perfect! That is very easy to describe with DP: ways[i]=ways[j], using the same notation as above. Whenever we make a new series, in what we labeled case B.

That's all very well, but a little bit of critical thinking should tell you that this won't work. How can you ever produce any number greater than one? To solve this, consider what data should give more than one way. One example might be from the data 9, 7, 8, 6. You could make, at length three and ending on 6, both 9-7-6 and 9-8-6. That's easy, then--you found the same pre-existing longest length twice! This is what we called case C earlier, and now we have something to put in it. Whenever we produce a series of length equal to the longest one so far, we add set ways[i] to ways[i]+ways[j], to allow for the number of ways to get each pre-existing series.

There's just one thing remaining to be considered. (It's always a bad thing if you haven't thought about one piece of the problem. Odds are very much against its working out accidentally.) Anyway, that one thing is that we need the number of different cost-combinations, not day- combinations. Think about it; day-combinations are what we generated above. At this point, someone with less faith in DP than I would start to panic. "How could we possibly do that?" our hypothetical friend Fred might say. &qout;We'll have to keep track of which series we've already used for each day. There are so many different possible series, there's no way we could remember them all. And if we don't, how will we know if we hit a repitition?"

Luckily for us believers, Fred is wrong. Think for a minute. How can you get the same combination of prices when you're building a series? Only when you build on to the end of series ending on different days that share a price. So, is there a way we can... eliminate them? Your gut reaction, after building up through so much DP, should be No. After all, if there's anything between the two days, it can be added on to the end of a series ending on the first day but not the second. (Time-travel would make this problem much more difficult.)

But, once we hit the second occurrence of the same price, the first one simply becomes obsolete. If you've already built a series or two from it, that's fine, but there's no reason to build more from it, for this simple reason: if you're building directly off of it, you're effectively ignoring the fact that extra things could come after the first in a series. You've already lost your chance to put anything else in-between. Instead, though, there might be extra days that you can put before the second. (These will increase its best, of course.) But, anything you could do ending on the first, you could also do ending on the second.

So, how can you harness this idea for your program? Simply ignore the first once you hit the second! Mark its best as -1, or make its price something ridiculous, or do anything at all so that your program knows not to build off of it. This will correct your way-count to exactly what you want. And, because we were very, very careful, the best array still works like a charm. So much for Fred.

There's only one more difficulty, and it is very easily addressed. How do you know the answer? How do you pick out the good answers from the bad and know the number of ways to get good ones? With a little thought, you should be able to write a routine to do the task, but there's a better way. This is the final touch that makes me really like this solution. All you have to do is run the main loop once more, with data[N] being zero. Any series of purchases at all of any length could have a zero tacked on to its end, because all inputs were required to be positive, each separate series will make another way to have a series ending on data[N]. After this final pass through, output best[N]-1 and ways[N].

This time, we really are done. I hope that made sense; if you don't have a picture of exactly what you're trying to do, look at the code, but also go back and reread the explanation. Much more important than understanding individual DP problems is understanding the logic behind them. Once you can do that, they're short, easy, and essentially free points. Anyway, here's Reid Barton's interpretation of everything I just said. (Yes, his is a lot shorter, but mine was easier to understand.)

#pragma option -O2
 
#include 
 
ifstream input( "INPUT.TXT" );
ofstream output( "OUTPUT.TXT" );
 
int days;
long prices[5001];
int len[5001];
unsigned long cnt[5001];
 
void read_prices( void );
void compute( void );
 
int main( void )
{
    read_prices();
    compute();
    output << len[0] - 1 << ' ' << cnt[0] << '\n';
}
 
void read_prices( void )
{
    int i;
    
    input >> days;
    prices[0] = 100000;
    days++;
    for (i = 1; i < days; i++)
        input >> prices[i];
}
 
void compute( void )
{
    int i, j, l;
    long oldp;
    
    for (i = days - 1; i >= 0; i--)
    {
        len[i] = 1;
        cnt[i] = 0;
        for (j = i+1; j < days; j++)
            if (prices[j] < prices[i] && len[j] + 1 > len[i])
                len[i] = len[j] + 1;
        if (len[i] == 1)
            cnt[i] = 1;
        else
        {
            l = len[i] - 1;
            oldp = -1;
            for (j = i+1; j < days; j++)
                if ((len[j] == l) && (prices[j] < prices[i]))
                    if (prices[j] > oldp)
                    {
                        oldp = prices[j];
                        cnt[i] += cnt[j];
                    }
        }
    }
}

### Alice ###

solutia se bazeaza pe faptul ca poti paria orice valaore (chiar si

rationale)

programare dinamica :

c[0][0] = 1 ;

c[i][j] = min (1-p[i][j])*c[i-1][j] , (1+p[i][j])*c[i][j-1])

p[i][j] = (c[i-1][j] - c[i][j-1])/(c[i-1][j] + c[i][j-1]) ;

c[i][j] = procentul maxim care se poate obtine garantat. (de aceea c[0][0] =

1 asta e unitatea de masura )

p[i][j] = cat la suta pariez din cat am la acel moment

                daca e negativ pariez pe negru , daca nu pe rosu

solutia e in c[n][r]*val ; (val e x$ la noi )

Rezolvarea de la amax urmeaza sa fie si ea publicata „intr-un numar viitor”.

Voi atasa acestui mesaj si datele de intrare/iesire de la toate problemele precum si o solutie corecta pentru fiecare problema.

Clasamentul de mai sus este final. Nu se accepta contestatii. In fond nu a fost decat un concurs in care sa va verificati fortele in vederea participarii la ONI. Aveti atasate fisierele de intrare/iesire/solutiile corecte, puteti sa va verificati problemele sa vedeti ce ati gresit. Foarte multe erori de compilare au aparut din neatentie. Tineti minte ca la un concurs adevarat aceste greseli se platesc cu multe puncte pierdute. Va recomand sa fiti mai atenti in pregatirea surselor pentru evaluare.

In final, as vrea sa-i multumesc in mod deosebit lui Mugurel Ionut Andreica, fara de care acest concurs nu ar fi fost posibil. De ce? Pentru ca el a furnizat 7 dintre cele 11 probleme propuse spre rezolvare, impreuna cu evaluatoarele aferente si cu datele de intrare/iesire corespunzatoare. De asemenea, el a avut o multime de idei in legatura cu concursul. (Mersi fain de tot, Mugurel)

Sper ca acest concurs nu va fi si ultimul de acest fel. Poate se vor gasi printre voi cativa mai curajosi care sa vrea sa organizeze si ei astfel de concursuri. Eu voi fi primul care ma voi inscrie ;-)

Bafta la ONI!


TESTDATA.ACE
  
Reply | Reply All | Forward Previous | Next

© 2002 Mail.com. All rights reserved.