[QUOTE=Dingbats;1413382]I've read of this sort of problem before.
Just tried it with -50 and 50 and the results are "normal": as for others, for example -20 (and less) till 200 with various randoms - all "normal".
Sugestion:
copy everything from this project into a completely new project (different name, folder, etc) and then compile - don't ask me why: somebody else will have to answer that.

When it doesn't work >= sorry. I'm only a hobby writer and with my "corrections" it worked (works) fine.[/QUOTE]

Thank you very much for your help, even though your solution didn't work for me it got me to messing around with the other numbers some more and I managed to get it to work with:

randomNumbers[a] = rand() % ((rangeNums[20] + 1) - rangeNums[0]) + rangeNums[0];

I am pretty sure that I had tried this before with failure since it is the same as the statement above it, but I guess I hadn't. And since I was working with negatives I guess I assumed that it would have to be a - 1 instead of + 1. But thanks for your help and have a great night, marking thread as solved.

[QUOTE=Dingbats;1413207]change line 48 to:
randomNumbers[a] = rand() % ((rangeNums[21] - 1) - rangeNums[0]) + rangeNums[0];
(all slots occupied)

change lne 91 to:
if(countOccurances[d] != 0)
(no extra '*' printed with multiples of 10)

then it seems to work.

I hate working with comparison with numbers in loops but it is sometimes so unavoidable!
Nice program.[/QUOTE]

Thanks for the help. The problem with the *'s and #'s has been taken care of, I can't believe that I didn't think of that, just had a lot going on and it didn't cross my mind. As for the first problem, changing rangeNums to 21 from 20 did not solve that problem at all. When I changed it and put in to start at -50 with 50 randoms generated, all of the randoms that it generated were positive and in the thousands, very random too, like one would be 2983 and another would be 5469, etc.. So, I am not sure why changing to 21 would have made that kind of drastic change but it did. Anyone have any idea as to how to fix this, I am exhausted on ideas and would like to get this program done and over with, this one has taken me way to long to complete and this is the only problem that I am experiencing then I'm done with it. Thanks for any help anyone can offer on this, and thanks for your help Dingbats.

Philosophy 3 Light Poster

I have created a histogram program that has the user enter the lower limit of the range, then generates a 20 number array with that number at array[0] and the lower limit + 20 at array[20]. It then does a random number generation where 85% of the randoms are within the range and 15% are outside, and counts how many fall outside of the range. Then it counts occurances and prints a histogram that shows the amount below range, then prints the range (number, count, #'s or 's), a # sign is printed for every 10 occurances that a number is counted and a for every 1 after that 10 or if there are not 10 occurances. Just wanted to explain what the program did to allow for better knowledge of the situation.

Now, my problem is that whenever the user enters a negative number whose number does not fall into a positive range, such as user enters -50, creates a range of -50 to -30, as opposed to entering -10 and range is -10 to 10, there seems to be a problem with the randoms generating any occurances of the last 2-3 slots in the array, array[18 through 20], sometimes it's just the last 2, sometimes the last 3, never more than the last 3 slots though. I have tried many many negative numbers where the entire range stays negative and this happens to every one. Now if the range falls into positive, or even ends a 0 ...

[QUOTE=VernonDozier;1409492]You're welcome. Regarding pausing the program, try this thread and the links in it. The concensus seems to be: clear stdin using the "ignore" command, then use cin.get().

[url]http://www.daniweb.com/forums/thread126418.html[/url]

Not sure if this link from WaltP is already in the trhead, but if not, check this one out.

[url]http://www.gidnetwork.com/b-61.html[/url]

Using eof() is often advised against because, as mentioned, the steam won't hit the end of the file after it reads the last piece of data, but will go one read attempt beyond. It's not so much a matter of what to use, but using it correctly, but I suppose using good() might be better than using eof() because it checks more things. eof() is fine if you have some understanding of what it does, but it's a bit counterintuitive so often people use it incorrectly. But if it ain't broke, don't fix it![/QUOTE]

Alright, well, that gives me a pretty good idea of what to use to exit the program properly, I hated the idea of using something like system("pause"), etc.. So now I have something more to go by. Since my program is working fine at the moment, gives no errors and returns all of the correct information, then I will leave it with .eof for the moment being. I will take note of .good for future use and will likely try to avoid .eof any time that I can get away with it because I do understand the problem with using .eof in certain situations and how .good ...

[QUOTE=VernonDozier;1409191]>>but I am having a problem with it even going into a while loop to be able to test it

That's part of the testing. You've narrowed down the problem considerably. It never gets into the loop.

I have closed the files previously and just re-opened right before this loop, when they re-open does the pointer in the file go back to the beginning automatically, I would think it does but I honestly do not know.

I would definitely not assume anything after I have opened and closed a stream, then reopened it.

If you want to reopen a file and start from the beginning, check whether it's closed first, and RESET the stream by clearing any bad/eof/fail bits if it's in a failed state.

[url]http://www.cplusplus.com/reference/iostream/ios/clear/[/url]

Check to make sure the stream is good and check to make sure it's open and check to make sure it's not in an eof state. Checks, even redundant ones, never hurt.
[url]http://www.cplusplus.com/reference/iostream/ifstream/is_open/[/url]
[url]http://www.cplusplus.com/reference/iostream/ios/good/[/url]
[url]http://www.cplusplus.com/reference/iostream/ios/eof/[/url]

You probably won't need to, but you can always set the pointer manually:
[url]http://www.cplusplus.com/reference/iostream/istream/seekg/[/url]

and it, again, never hurts to check to make sure you're at the begginning of the file.

[url]http://www.cplusplus.com/reference/iostream/istream/tellg/[/url]

I doubt you'll need all or even most of these, but between them, you should be able to verify the stream is good and fix it if it isn't.[/QUOTE]

Well, I managed to get it working, it was as simple as putting a .clear for each file after I opened them, then taking WaltP's advice and ...

[QUOTE=VernonDozier;1409098]I'll throw in some debugging hints rather than analyze the code itself.

You need to find out WHERE and HOW these files are considered different. To that end, for each itereation through the loop, display wehn the test PASSES, not just when it fails. It may fail immediately after reading the first character. It may always fail at the very end. Take out the testing code later, but you need more thorough printouts.

Something like this:

File 1: abcdef
File 2: abddef

Output:
File 1 character 1='a'(Ascii=97)
File 2 character 1='a'(Ascii=97)
They match
File 1 character 2='b'(Ascii=98)
File 2 character 2='b'(Ascii=98)
They match
File 1 character 3='c'(Ascii=99)
File 2 character 3='d'(Ascii=100)
They do not match

It'll help you nail down EXACTLY where the problem is.[/QUOTE]

I completely understand what you mean here, but I am having a problem with it even going into a while loop to be able to test it, here is what I have right now:

[CODE]
inputFile.open(inputFileName, ios::in);
outputFile.open(outputFileName, ios::in);

char a;
char b;

cout << "This is right before the while loop" << endl;
while(!inputFile.eof() && !outputFile.eof())
{
cout << "this is right inside of the while loop" << endl;
inputFile.get(a);
outputFile.get(b);
cout << "Ch. A: " << a << " (Ascii = " << int(a) - int('0') << ")" << endl;
cout << "Ch. B: " << b << " (Ascii = " << int(b) - int('0') << ")" << endl;

if(a != b)
{
    cout << "Characters do not match" << endl;
} ...

[QUOTE=alexchen;1409060][CODE]cout<<sizeof(original file)<<endl;
cout<<sizeof(new file)<<endl;[/CODE][/QUOTE]

I just tried that, added that to my code at the end and replaced the original file and new file with the input and output files and the sizeof comes up the same for both. If this is what you were getting at.

Philosophy 3 Light Poster

I am working on the last part of an encryption/decryption program and have to compare the original input file to the final output file character by character to ensure that they are identical. I have tried a few different ways to do this to no avail. When I tried this code:

[CODE]
inputFile.get(inputChar);
outputFile.get(outputChar);

while(inputFile.good() && outputFile.good())
{
if(inputChar != outputChar)
{
cout << "The files are not identical\n\n\n";
return 1;
}

    inputFile.get(inputChar);
    outputFile.get(inputChar);

}

if(inputFile.eof() && outputFile.eof())
{
cout << "The files are identical.\n\n\n" << endl;
}
else if(inputFile.eof() || outputFile.eof())
{
cout << "One of the files has ended before the other, they are not identical." << endl;
}[/CODE]

It seems to go straight to telling me that one of the files has ended before the other and that they are not identical. I also tried:

[CODE]
while (inputFile.get(inputChar))
{
if (!outputFile.get(outputChar) || (inputChar != outputChar))
{
cout << "The files are not identical" << endl;
}
}
if (!outputFile.get(outputChar))
{
cout << "The files are identical" << endl;
}
else
{
cout << "The files are not equal";
}*/[/CODE]

And this is also telling me that they are not identical when I run the program. The two files are exaclty the same size, there is only one character in each of them (that's what I am testing with at the moment, just the letter a in each file), there is no extra characters or spaces in either of the files, the only difference between the two is ...

[QUOTE=VernonDozier;1408106]You're welcome. I'm not sure about the answer below, but I think it's possibly close enough to justify posting it, so just remember the disclaimer. Don't bank on the explanation being 100% (or even 90%) correct. If you're interested, it might be worth starting another thread. There are definitely people who DO know for sure.

But here goes...

An ifstream returns a null pointer if it's in a state where you can't read from it. There are three bits that can be set: eofbit, failbit, badbit.. When >> tries to read an integer, but can't because there are none left, I think the eofbit and the failbit are set. This in turn causes there to be a null pointer. See this page:

[url]http://www.cplusplus.com/reference/iostream/ios/operator_voidpt/[/url]

In particular, see this part of it:

So you try to read from the stream here:

[code]
while(encryptionFile >> decInt)
[/code]

and the failbit gets set, so the stream points to null(0), so your while condition fails. The problem you had before was that the stream failed INSIDE of the loop and you were only checking at the TOP of the loop. The stream doesn't fail when you read the LAST integer. It fails AFTER that(when it tries to read an integer and can't).

It's a fairly common mistake. People test the stream with the eof() function at the top of a loop, then read it inside the loop and have the same difficulty. The stream is still considered a valid stream even after the last piece ...

Drew Barrymore, Jennifer Lopez, and Claire Danes, also Zhang Ziyi mentioned above is very beautiful as well.

[QUOTE=VernonDozier;1407939]>> Any idea on as to why it is repeating that decryption 2 times

Most likely the input stream isn't failing when you think it is. The stream reads in the last integer and when it does, it hasn't failed yet. It fails when it attempts to read in a new integer and can't.

In other words it fails on line 3, but you don't check that before proceeding to lines 4 through 6. The check will occur on line 1, but by then you've gone through once too many times.

[code]
while(encryptionFile)
{
encryptionFile >> decInt;
decVal = decInt - modSum;
endDec = int(decVal) + int('0');
outputFile << char(endDec)
}
[/code]

Try changing it to this and see if it works better(or do it the way you have it above and check the encryptionFile stream AGAIN after line 3 above:

[code]
while(encryptionFile >> decInt)
{
decVal = decInt - modSum;
endDec = int(decVal) + int('0');
outputFile << char(endDec)
}
[/code][/QUOTE]

Ok, I did what you said and changed the code to:

[CODE]
while(encryptionFile >> decInt)
{
decVal = decInt - modSum;
endDec = int(decVal) + int('0');
outputFile << char(endDec)
}
[/CODE]

And it worked great, it only output one a instead of 2 and output is identical to input. I then tried it with 2 letters in the input, ab. This also worked, so did a sentence as well as a paragraph with punctuation included. So, now my question is exactly how does the little amount of changing that ...

[QUOTE=Fbody;1407907]Sorry about double, ran out of edit time.

[B]>>Well, if I did it with a switch statement then wouldn't it still take up just as much room. [/B]
Depending on how you format things, it could take up a little less. You would be using 3 lines of code for each case instead of 4 as you've formatted it now. But you'd be trading the braces for case and break statements.

EDIT:
Oops, overlapped a little.
A stringstream is almost just like a file stream. The main difference is that it uses a string as a temporary storage "buffer" in memory instead of a physical file on a disk. [URL="http://www.cplusplus.com/reference/iostream/stringstream/"]Here is some information.[/URL][/QUOTE]

I will have to read up on that for future reference, thanks for the information. I like what you posted about using islower and isupper as opposed to using a switch statement. A switch statement may save me about 50-60 lines or so, but I would still be stuck with well over 100 lines of code. I am going to work with isupper and islower and see how that works, because just looking at the code you posted I can see how it should work properly, plus I'm still waiting on the professor to send me some valid and invalid software codes that he is going to use to test this program so I can get an actual idea if I am off on my calculations. But using ones that I made up and that another student ...

[QUOTE=Fbody;1407872]If you detect the "case" (upper/lower), then use mathematics, you should be able to save a ton of code. I think you may want to consider something like this:[CODE]
if (islower(input)) { //detect a "lower" case character
value = 10 + (input - 'a'); //perform the translation
} else if (isupper(input)) { //detect a "upper" case character
value = 36 + (input - 'A'); //perform the translation
}[/CODE]
You'll have to test it, and possibly do some tweaking, to make sure its results are consistent, but you should be able to perform basic arithmetic operations on chars like this and save alot of code. Just make sure you comment it well.[/QUOTE]

Thank you for this, I will have to work with it and see what I can come up with. As for the encryption/decryption thread, this one and that one are completely different programs and I have never used stringstream before so your response didn't fully make sense. But I think I am getting close to getting that one going, thank you very much for your help.

[QUOTE=Fbody;1407896]I have a feeling your conversion process is what [URL="http://www.daniweb.com/forums/thread329755.html"]your other thread[/URL] is about. Take the result of the equation I suggested in [URL="http://www.daniweb.com/forums/post1407872.html#post1407872"]this post[/URL] and combine it conjunction with an output manipulator to produce a continuous string of padded "numeric" characters. Then, when reading the file, use a character-based input function to read groups of 4 bytes into a stringstream, then extract from the stringstream to an integer.[/QUOTE]

No, actually these are not tied together in any way. They are completely seperate programs. The other thread was just trying to clean up some code on a program that is already finished, this one is completely different. Thanks for your help though.

[QUOTE=VernonDozier;1407832]If you don't want to tackle the zero padding and just add spaces instead, then yeah, that looks OK for the encryption. As for the decryption, assuming you are adding the spaces, as you need to read in an integer using the >> operator. You read an integer from the encrypted file, not a character, and you use the >> operator. Then you take the integer and subtract what you added before and add what you subtracted before (i.e. modSum and '0'), then you convert it to a character and if you did everything right, it'll be the original character.

Make your life easy and start with a string like "0", "1", "2", "00", then "11", then "01", then "22", then "23", etc. Pick really easy strings to convert so you can check them easily. When those all work, start doing the more complex ones. If you start with "A628TU42", you'll never find your bugs.[/QUOTE]

Ok, the first thing I wanted to do was just to make sure that I get a letter as output from the decryption, since up till now it has been a bunch of integers that were negative. So I made the following changes to the decryption:

[CODE]while(encryptionFile)
{
encryptionFile >> decInt;
decVal = decInt - modSum;
endDec = int(decVal) + int('0');
outputFile << char(endDec);
}[/CODE]

Here is exactly what is happening, when I run the program:

The modSum is calculated correctly at 4922 entering an encryption string of zxzxzxzxzxzxzxzxzxzxzxz. This is then correctly added to ...

635

[QUOTE=SgtMe;1407801]Couldn't you use a switch instead of having all of those if statements? I'm sure they will be an even better method than that. Do you actually need the lower case bit? Or could 'z' and 'Z' be the same? If so, then you just need one line to capitalize it before you check which letter it is. Check this out:
[url]http://www.daniweb.com/forums/thread100207.html[/url][/QUOTE]

Well, if I did it with a switch statement then wouldn't it still take up just as much room. This is due to the fact that the user can enter a-z or A-Z and each letter is a different value between 10 and 61 respectively. I remember seeing something once about a loop that could work with each type, not sure about that though. I just would think that there would be a way to consolidate this than to have 200+ lines of code just for placing values to letters. If you think a switch statement would work for this could you give a small example. The post that you linked was not what I am needing to do for this, as during user-entry they will be entered as either lower case or upper case and have to be handled as they are entered.

Philosophy 3 Light Poster

I am just wondering if there is a way to put the following code into a loop or two so that it is easier on the eyes and doesn't take us so many lines. I have not been able to think of a way to do this with so many different characters all equaling a different amount. By the way this is for a program that computes software code validity, and the program works fine as is, just trying to consolidate some code. I apologize for the wall of code here. Thank you for your help in advance.

[CODE]for(int b = 0; b <= 19; b++)
{
if(softChar[b] == 'a')
{
alphaValue = 10;
}
else if(softChar[b] == 'b')
{
alphaValue = 11;
}
else if(softChar[b] == 'c')
{
alphaValue = 12;
}
else if(softChar[b] == 'd')
{
alphaValue = 13;
}
else if(softChar[b] == 'e')
{
alphaValue = 14;
}
else if(softChar[b] == 'f')
{
alphaValue = 15;
}
else if(softChar[b] == 'g')
{
alphaValue = 16;
}
else if(softChar[b] == 'h')
{
alphaValue = 17;
}
else if(softChar[b] == 'i')
{
alphaValue = 18;
}
else if(softChar[b] == 'j')
{
alphaValue = 19;
}
else if(softChar[b] == 'k')
{
alphaValue = 20;
}
else if(softChar[b] == 'l')
{
alphaValue = 21;
}
else if(softChar[b] == 'm')
{
alphaValue = 22;
}
else if(softChar[b] == 'n')
{
alphaValue = 23;
}
else if(softChar[b] == 'o')
{
alphaValue = 24;
}
else if(softChar[b] == 'p')
{
alphaValue = 25;
} ...

[QUOTE=VernonDozier;1407019]You're welcome. Definitely ask for clarification. It would be silly to jump through all the hoops and then find out that you were actually allowed to stick a space between integers. Sometimes professors aren't as precise with their language/requirements as they need to be.

Delete lines 69 -74 and rewrite that decryption segment from scratch. Presumably you want to do the exact opposite of what you did to encrypt, so list the steps that you did to encrypt, then do the exact reverse in reverse order to decrypt, so if you WROTE an integer to the file as the LAST step of encryption, you need to READ an integer from a file as the FIRST step in decryption.[/QUOTE]

Ok, I got a response stating that I am supposed to "Pad each result with zeros so each will be 4 digits even if the mod resulted in a number less than 4 digits. Then when reading in you can convert those 4 appropriately." Then it goes on to say that the use of spaces, commas, etc. allow hackers to distinguish elements of the code and they would figure it out to easily. Then he says that this would require "multiple different modifiers for the letters in a pattern based on something different than a single prime." He then states that if my code can't easily be converted to allow this then I can go ahead and use spaces and to just let him know which I use. So, I guess I'll ...

[QUOTE=VernonDozier;1406987]You may need to go back to your professor for clarification on what's required. First, let's parse this sentence:

I would read it as "no spaces allowed between the numbers", but others may read it differently. If you were ALLOWED to stick spaces in, your problem of where one starts and the other stops is no longer a problem.

But let's assume that I'm reading this correctly and that you are NOT allowed to do that. How then does one distinguish one integer from the next? Perhaps there's a math trick in there (i.e. you are guaranteed that each integer will be a certain number of digits). You could analyze every possible combination and perhaps there may be some conclusion you can draw on the value of modSum as far as number of characters or whatever. I doubt it though, particularly if this isn't a math class. You should assume modSum can be any number from 0t to 7043, so no help there as far as the number of digits.

Your other alternative is to write and read from the file as binary data. Integers will take the same number of bytes each time, so you can delineate them that way. But then you'd have to compare the files using a binary editor like Hex Editor Neo. Doubtful.

How advanced is this class anyway? Is this the kind of stuff your professor throws at you (i.e. you have to find some "gimmick" to get it to work) or is this ...

[QUOTE=VernonDozier;1406797]You'll want to take a look at your encrypted file. Seems to me it will end up being a long line of digits with no spaces, tabs, commas, etc. dividing them:

[code]
345423562352345423512341234234534253455432454325
[/code]

or whatever, representing a bunch of integers. Here's the problem. When you open the file again to read in a bunch of integers, how do you know when one integer stops and the next one starts? And if you're WRITING integers to the file to encrypt, why are you not READING integers when you decrypt. I would imagine you want to read in exactly what you wrote out, then do whatever conversions you need to do.

Thirdly, this code seems pointless. You calculate a value for decVal, but never use it.

[code]
while(encryptionFile.get(decChar))
{
decVal = decChar - modSum;
endDec = int(endDec) + int('0');
outputFile << endDec;
}[/code][/QUOTE]

Yes, I noticed the same thing with the encrypt file. That once the encryption is done to the original text file and is being put into the encrypt text file that there is no way to specify which numbers go with which original character. Yet, I also do not know how to do this. The assignment states that the encrypt text file will just be a long string of numbers that represent the characters in the original text input file. If I told it to add a space or something after each time it does a conversion that should solve the separation issue, which should be easy enough ...

Philosophy 3 Light Poster

I am working on an Encryption/Decryption program for class and have run into a problem. I seem to have gotten the encryption correct, but I am unable to decrypt what was encrypted in order to get an output equal to what originally went in.

Here is the code I have so far:

[CODE]#include

include

using namespace std;

int main()
{
char userInput[24], inputFileName[51], encryptionFileName[51], outputFileName[51], encChar, decChar;
int weightedSum = 0, modSum = 0, currentPos, intValue, fileValue, encVal, endEnc, decVal, endDec;
fstream inputFile;
fstream encryptionFile;
fstream outputFile;

cout << "Input string: ";
cin >> userInput;

//**********Create Encrypt/Decrypt Value*************//

for(int i = 0; i <= 23; i++)
{
    intValue = int(userInput[i]) - int('0');

    currentPos = 1 + i;
    weightedSum += intValue * currentPos;
}

modSum = weightedSum % 7043;

cout << "modSum: " << modSum;

//***********Encryption Starts Here*************//

cout << "Enter the name of the input file: ";
cin >> inputFileName;

inputFile.open(inputFileName, ios::in);

if(!inputFile)
{
    cout << "\n\n\nThe file titled \"" << inputFileName << "\" cannot be opened or does not exist." << endl;
    cout << "\n\nPress any key to exit . . .";
    _getch();
    return 1;
}

cout << "Enter the name of an encryption file: ";
cin >> encryptionFileName;

encryptionFile.open(encryptionFileName, ios::out);  

while(inputFile.get(encChar))
{
    encVal = int(encChar) - int('0');
    endEnc = encVal + modSum;
    encryptionFile << endEnc;
}

inputFile.close();
encryptionFile.close();

//********DECRYPTION STARTS HERE**********//

cout << "Name of output file: ";
cin >> outputFileName;

outputFile.open(outputFileName, ios::out);
encryptionFile.open(encryptionFileName, ios::in);

while(encryptionFile.get(decChar))
{
    decVal = decChar - modSum;
    endDec = int(endDec) + ...

[QUOTE=StuXYZ;1336760]Ok first off, welcome to daniweb, and thank you for writing a clear post with code blocks and not-too much and not too little code!

Ok to your problem, you have unfortunately made a couple of logic errors. First, consider your loop, [icode]for(int c=2;c<= num;c++)[/icode]. This will test each possible factor up and [B]including[/B] the number itself. If this was the only error, ALL of your test numbers [except 2] would be reported as not-prime.

Now, let us consider the inner part of the loop, numPrime is set true each and every time round the loop. Then it is set if a factor is found. BUT then it is tested, and regardless if it is either true/false you execute a break statement. Therefore,you only test if the number divides by 2. No other numbers. You can see this if you add a line [icode]cout<<"Test number c == "<<c<<endl;[/icode] as the first instruction of the loop.

So to remedy you could do something like this
[code=c++]
numPrime=true;
for(int c=2;c<num;c++)
{
if (num % c == 0)
{
numPrime=false;
break;
}
}

if (numPrime == true)
std::cout<<"Number prime"<<std::endl;
else
std::cout<<"Number not prime"<<std::endl;
[/code]

Some simple improvements that will help, you only need to test up to the square root
of the number, since if ab=N^2 and a=N+x and b=N+y where x, y and >=0 then
a
b== N^2 + N(x+y) +xy. Which can only hold if x,y==0.[/QUOTE]

I managed to get it work using the issues pointed out in your post. I can't ...

[QUOTE=VernonDozier;1336808]In addition to what StuXYZ said, I suggest using smaller test cases than 777 and 7777. It'll break at 9, calling it prime. That's because, as StuXYZ mentioned, due to the break statements, you don't really have a loop and thus don't test for anything higher than 3.[/QUOTE]

Yes, I know what you mean. I personally had not tested it with anything high, but then told my girlfriend to test it with random numbers just to see it's functionality and she tried 777 and that's where I saw the problem. I just understand what you mean about the break, I seem to be very break happy. I will definitely be trying to use less breaks and start making sure they are in the right place. Thank you for your response.

[QUOTE=StuXYZ;1336760]Ok first off, welcome to daniweb, and thank you for writing a clear post with code blocks and not-too much and not too little code!

Ok to your problem, you have unfortunately made a couple of logic errors. First, consider your loop, [icode]for(int c=2;c<= num;c++)[/icode]. This will test each possible factor up and [B]including[/B] the number itself. If this was the only error, ALL of your test numbers [except 2] would be reported as not-prime.

Now, let us consider the inner part of the loop, numPrime is set true each and every time round the loop. Then it is set if a factor is found. BUT then it is tested, and regardless if it is either true/false you execute a break statement. Therefore,you only test if the number divides by 2. No other numbers. You can see this if you add a line [icode]cout<<"Test number c == "<<c<<endl;[/icode] as the first instruction of the loop.

So to remedy you could do something like this
[code=c++]
numPrime=true;
for(int c=2;c<num;c++)
{
if (num % c == 0)
{
numPrime=false;
break;
}
}

if (numPrime == true)
std::cout<<"Number prime"<<std::endl;
else
std::cout<<"Number not prime"<<std::endl;
[/code]

Some simple improvements that will help, you only need to test up to the square root
of the number, since if ab=N^2 and a=N+x and b=N+y where x, y and >=0 then
a
b== N^2 + N(x+y) +xy. Which can only hold if x,y==0.[/QUOTE]

Thank you for your prompt response to this, I will take your advice and look into ...

[QUOTE=prvnkmr449;1336767]I don't think you work hard to solve this problem or you attach wrong code please try once more you have many more exception then you mention even not provide the list also............Basic logic behind finding prime number is that prime number is only divisible by itself and 1 thats all about prime number.............
Best Of Luck[/QUOTE]

This is the code regarding just the prime number checker in my program. I did not include all of the other code in the program because it is functioning correctly and does not affect this. I know how to find prime numbers, etc., but this problem is dealing specifically with it giving the correct answer on some and wrong answers on higher number problems. So, I feel that the code that I put in the post is relevant. Thank you for response.

Philosophy 3 Light Poster

First off, I do want to state that I have read the forums and have not found an issue directly regarding this exact problem, though it is possible I may have overlooked it or something and if so please just point me in the right direction and I will leave you alone.

The program I have been writing is a prime number checker, just to check to see if the number input is prime and list numbers up to that number that are prime also. The program is working fine, the listing functions correctly and it properly identifies whether the input is prime or not, except for one exception. When I entered the number 777 into the program, it states that it is prime, which is incorrect, same with 7777. I have been trying to figure this out for a couple days now to no avail. So, any help will be greatly appreciated. Here is the snippet of code that handles the input checker:

[CODE]void userPrime(int num)
{
if(num == 2)
{
cout << "The user entered the number, " << num << ", this is a prime number.\n\n";
}
else
{
for(int c = 2;c <= num;c++)
{
numPrime = true;
if(num % c == 0)
{
numPrime = false;
}
if(numPrime == true)
{
cout << "The user entered the number, " << num << ", this is a prime number.\n\n";
break;
}
else
{
cout << "The user entered the number, " << num << ", this ...

StuXYZ commented: Excellent first post +3
prvnkmr449 commented: Your code never print the list , it always print value of num +0