1. ## Combination Crash

Hi everyone, I'm pretty lame at writing source codes so I have no doubt that this will look like hell to you all. But basically this is meant to be a code is that prints out every possible combination in accending order for 7 numbers in any number you choose. Like a list of lottery combinations. I thought I could do it and I did somewhat. It works at first but if the number gets to big it stops printing. Can anyone please tell me what to do? It would really mean a lot. Its not homework or anything, its just an obstacle I can't overcome by myself. I think it has something to do with the arrays but don't know how to deal with it. Please help.

Code:
#include <iostream>
#include <fstream>
#include <string>
#include <cstdlib>
using namespace std;
int main () {
int P [] = { 1, 1, 1, 1, 1, 1, 1};
int ka [] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0};
int L, H, z, f, y, x, p, k, a, c;
string line;
z=6; p = 0;
ofstream myfile ("Factorial.txt"); if (myfile.is_open())
cout << "Please type the highest number: ";cin >> L; ++L;
loop: y=z; while (P [z] != L)  {
H = 0; a = z; c = (z-1); f = 21;

ka[1] =  (P[1]-P[0]);
ka[2] =  (P[2]-P[0]);
ka[3] =  (P[3]-P[0]);
ka[4] =  (P[4]-P[0]);
ka[5] =  (P[5]-P[0]);
ka[6] =  (P[6]-P[0]);
ka[7] =  (P[2]-P[1]);
ka[8] =  (P[3]-P[1]);
ka[9] =  (P[4]-P[1]);
ka[10] =  (P[5]-P[1]);
ka[11] =  (P[6]-P[1]);
ka[12] =  (P[3]-P[2]);
ka[13] =  (P[4]-P[2]);
ka[14] =  (P[5]-P[2]);
ka[15] =  (P[6]-P[2]);
ka[16] =  (P[4]-P[3]);
ka[17] =  (P[5]-P[3]);
ka[18] =  (P[6]-P[3]);
ka[19] =  (P[5]-P[4]);
ka[20] =  (P[6]-P[4]);
ka[21] =  (P[6]-P[5]);

while ( ka[f] != 0 ) { if (ka[f] == 0) {++H, --f;}  else --f; }

while ( c != -1) { if (P[a] <= P[c]) {++H, --a, --c;} else  {--a, --c;} }

if (H == 0) {myfile << P[0] << "\t" << P[1] << "\t" << P[2] << "\t" << P[3] << "\t" << P[4] << "\t" << P[5] << "\t" << P[6] << "\n";};
if (k != 0) {++P [z], p = 0;} else p = 0; }; while (y != 0)
if ( P [y] != L) goto endloop; else P [y]=1, --y, ++P [y]; goto endloop;
endloop: while (P[0] != L) {goto loop;} myfile.close(); return 0;}

2. Dear lord... Your code is almost as nasty looking as Sabastiani's sig. I am going to post your code in a reader friendly format for everyone, ok?

Code:
#include <iostream>
#include <fstream>
#include <string>
#include <cstdlib>
using namespace std;

int main () {
int P [] = { 1, 1, 1, 1, 1, 1, 1};
int ka [22] = {0};
int L, H, z, f, y, x, p, k, a, c;
string line;

z=6; p = 0;
ofstream myfile ("Factorial.txt");

if (myfile.is_open())
cout << "Please type the highest number: ";

cin >> L;
++L;

do {
y=z;

while (P [z] != L)  {
H = 0;
a = z;
c = (z-1);
f = 21;

ka[1] =  (P[1]-P[0]);
ka[2] =  (P[2]-P[0]);
ka[3] =  (P[3]-P[0]);
ka[4] =  (P[4]-P[0]);
ka[5] =  (P[5]-P[0]);
ka[6] =  (P[6]-P[0]);
ka[7] =  (P[2]-P[1]);
ka[8] =  (P[3]-P[1]);
ka[9] =  (P[4]-P[1]);
ka[10] =  (P[5]-P[1]);
ka[11] =  (P[6]-P[1]);
ka[12] =  (P[3]-P[2]);
ka[13] =  (P[4]-P[2]);
ka[14] =  (P[5]-P[2]);
ka[15] =  (P[6]-P[2]);
ka[16] =  (P[4]-P[3]);
ka[17] =  (P[5]-P[3]);
ka[18] =  (P[6]-P[3]);
ka[19] =  (P[5]-P[4]);
ka[20] =  (P[6]-P[4]);
ka[21] =  (P[6]-P[5]);

while ( ka[f] != 0 )
{
if (ka[f] == 0)
++H,
--f;
}

while ( c != -1)
{
if (P[a] <= P[c])
++H
--a;
--c;
}

if (H == 0) {
myfile << P[0] << "\t" << P[1] << "\t" << P[2] << "\t" << P[3] << "\t" <<
P[4] << "\t" << P[5] << "\t" << P[6] << "\n";};
if (k != 0)
++P [z];
p = 0;
};

while (y != 0)
if ( P [y] != L)
break;
else
P [y]=1, --y, ++P [y];
} while (P[0] != L);

myfile.close(); return 0;
}
I also took the liberty of removing your goto statements since they weren't direly required this time 'round.

3. Is that an obfuscated C++ competition entry - if so, I would call it qualified, but if this is "your best attempt", then lame isn't really the right word:
1. Using goto where a break would do fine.
2. Using comma operators, even when it's not needed [it is EXTREMELY rare that they are ever needed].
3. Short variable names.
4. Multiple statements on single lines.
5. No determinable indentation.
6. Line breaks in weird places.
7. Duplicating the same statement on both sides of an if/else where a single statement is fine.
8. Using goto when a while loop would do fine.
9. Using while when if is really doing the same thing.
10. Using goto when "nothing" would do the same thing.

Code:
while ( ka[f] != 0 )
{
if (ka[f] == 0)
{
++H;
--f;
}
else
{
--f;
}
}
That's a bit reformatted from your code, but I'm pretty sure that the if-statement will not ever execute ++H, and the --f is on both sides of that.

Code:
if (myfile.is_open())
{
cout << "Please type the highest number: ";
}
cin >> L;
++L;
So if we don't open the fiel, we still ask try to read the input, just don't ask the question?

Code:
if (H == 0)
{
myfile << P[0] << "\t" << P[1] << "\t" << P[2] << "\t"
<< P[3] << "\t" << P[4] << "\t" << P[5] << "\t"
<< P[6] << "\n";
}
Other code before this line increments H - it is never decremented, so unless the loop runs for an extremely long period of time, I expect there will be no output.

--
Mats

4. Ok, now that we have a clear sample source code to work from, lets now look at the algorithm itself. First off, you are simply doing permutations, correct? Bearing that in mind, I cease to understand your code once you start trying to do the permutations. I mean, you are doing this very arbitarily, and why is the P array filled with all ones?

5. Originally Posted by matsp
1. Using goto where a break would do fine.
2. Using comma operators, even when it's not needed [it is EXTREMELY rare that they are ever needed].
3. Short variable names.
4. Multiple statements on single lines.
5. No determinable indentation.
6. Line breaks in weird places.
7. Duplicating the same statement on both sides of an if/else where a single statement is fine.
8. Using goto when a while loop would do fine.
9. Using while when if is really doing the same thing.
10. Using goto when "nothing" would do the same thing.
From hense forth refer to my code and not his. I disavvow any knowledge of every seeing his code in my whole life.

6. Originally Posted by master5001
From hense forth refer to my code and not his. I disavvow any knowledge of every seeing his code in my whole life.
I know - I was just trying to point out that it was probably not accidental that the code looked a bit weird. I've also formatted it (C-c . stroustrup, M-<, M->, M-x indent-region).

As to why the code isn't working, I have no idea - I tried to add some debug output and to step trhough it in gdb, but I have no idea what the thoughts behind the code is, so it's very hard to debug it.

--
Mats

7. Code:
P [y]=1, --y, ++P [y];
That is one of those nastiest of nasties right there... I would venture to guess segments of the code were copied and pasted off the net.

8. No segment was copied or pasted from the net. Like I said I'm not good source codes' I just got it to reflect what was going on in my head and overcame every problem that came my way. Kinda like Prision Break but without the dramatic music or Jodi Lynn O'Keefe. My only concern isn't how pretty or neat the code is, even though it really was a lot more hedious before it got here, but rather that it does what its meant to under any condition no matter what value I enter. It does to a point but if the number is large enough it will freeze whilst printing a line. Which is why I came here.

Surely an expert like master5001 would not only be able to identify to problem but present a solution short of starting from scratch. I know someone reading this is smart enough to tell me how to make it work when larger numbers are entered. I'd really appreciate it as I appreciate the time and responses spent on this so far.

9. Why thank you! ....hey wait a minute... I think I detect a hint of sarcasm.

Alright, lets start off qualifying the purpose of writing clean code. As many of the people who frequent the forums have come to know, my style is not always 100&#37; clean. I will cut out unnecessary intermediary variables and stuff that would be useful merely for the sake of keeping clean code. Though, my comments have always been sufficient for people on various dev teams I have been on in the past. Furthermore, you are asking for help and giving us something that is difficult to read. I mean sure stuff can be reformatted, but it benefits you to have a clean copy yourself.

Your convention that you use is currently stuck at using an array of no more than 22 elements without causing a seg-fault. Also, I find your code convoluted. Permutations are easy to think of if you think of having seven cups and x many legos. You simply exchange which legos are in each of the seven cups at any given time.

If you are strictly doing this for lottery number combo checking you can safely say something like

[1] [22] [31] [5] [7] [19] [3]

Is identical to

[22] [3] [7] [19] [1] [31] [5]

Right?

Given that knowledge you can straight loop through all the combos.

10. Originally Posted by koxson
No segment was copied or pasted from the net. Like I said I'm not good source codes' I just got it to reflect what was going on in my head and overcame every problem that came my way. Kinda like Prision Break but without the dramatic music or Jodi Lynn O'Keefe. My only concern isn't how pretty or neat the code is, even though it really was a lot more hedious before it got here, but rather that it does what its meant to under any condition no matter what value I enter. It does to a point but if the number is large enough it will freeze whilst printing a line. Which is why I came here.

Surely an expert like master5001 would not only be able to identify to problem but present a solution short of starting from scratch. I know someone reading this is smart enough to tell me how to make it work when larger numbers are entered. I'd really appreciate it as I appreciate the time and responses spent on this so far.
Of course someone here can do so -- in fact someone here has done so (I remember doing it myself once upon a time). Why not search the boards so I don't have to do it again?

11. Your question is not entirely clear. For example, what does this mean?
Code:
every possible combination in accending order for 7 numbers
in any number you choose
Do you mean COMBINATIONS, i.e., "7 choose n" where n is entered by the user?
Or do you mean PERMUTATIONS, i.e., all permutations of 7 numbers?
Also, you say it fails with large numbers ... how large?

12. He means if you have a pool of numbers: like

Code:
0   1   2   3   4   5   6   7   8   9
10  11  12  13  14  15  16  17  18  19
20  21  22  23  24  25  26  27  28  29
30  31  32  33  34  35  36  37  38  39
40  41  42  43  44  45  46  47  48  49
50  51  52  53  54  55  56  57  58  59
60  61  62  63  64  65  66  67  68  69
70  71  72  73  74  75  76  77  78  79
80  81  82  83  84  85  86  87  88  89
90  91  92  93  94  95  96  97  98 100
What are all the combonations of seven of those numbers? I didn't have that hard of a time following the question.

13. Tabstop, Are there any keywords that will help my find it in the 4,000 posts you have?

nucleon, I meant permaumatations. As for how a large, I gave the code in a smaller form so you guys would understand it easier. There were really 11 p[] arrays and not 7. which meant I had 56 ka[] arrays and not 22. z was equal to 10 and not 6. In that case the number 13 was too large. Otherwise the code is eactly the same. By my logic that means the problem is the same too. I'd post it if I didn't know it would pee everyone of all over again.

14. You wouldn't Pee me off.. I would simply recorrect it again and know that your knowledge of my thoughts is duly noted. I do not take much to heart, bud.

15. Originally Posted by koxson
Tabstop, Are there any keywords that will help my find it in the 4,000 posts you have?

nucleon, I meant permaumatations. As for how a large, I gave the code in a smaller form so you guys would understand it easier. There were really 11 p[] arrays and not 7. which meant I had 56 ka[] arrays and not 22. z was equal to 10 and not 6. In that case the number 13 was too large. Otherwise the code is eactly the same. By my logic that means the problem is the same too. I'd post it if I didn't know it would pee everyone of all over again.
Well, wait; permutation or combination? If it's always ascending order, it can't be permutation. Anyway I know we've had the permutation algorithm before (maybe search on "permutation problem"). The combination algorithm isn't that much different -- add 1 to the last element if you can; if you can't, go backwards until you can, add one there, and then follow the rest in increasing order. That is (say we're doing 1 through 9) after 1 2 7 8 9, I can't make 7, 8, or 9 larger; so I increase 2 to 3 and keep going: 1 3 4 5 6. (Edit: And to be clear, the reason I can't make 7 or 8 larger is that my combinations have to come in numerical order, and after 1 2 8 9 I'm stuck for the last number. So, you move backwards until the gap is more than 1, and then increase and move forward.)