OP
CrazedNerd
Guest
Yeah i think you're right ill try it later.The fix is to change %zu to %d in your printf statement.
Yeah i think you're right ill try it later.The fix is to change %zu to %d in your printf statement.
Yeah i actually don't think it matters...im just using a basic gcc compiler and it never whines about %zu/size_tYup I wouldn't write code like that but it made you think
Some compiler setups won't use %zu so just use %d or %u or something. If you like doing this type of stuff maybe try learning some C sort methods (bubble, merge, quick, etc).
(it's supposed to be "element,high")printf ("\n%zu was the highest occurring random number, at %i occurrences.\n", element, high);
element = number : 666
Yeah, but thats not how it worked, basically you can make the 666 as a 0 like you should because the frequency element could never be that...but it can't be 666 either...since srand is close to truly random, you'll get close to 100,000,000 for each number (one billion divided by 10)Spoiler: The 666 after the : is just the result if frequency[number] is not > than high. And since you don't care if the number is not > than high then you can make it anything you want, like 666 because you're not doing anything with it.
The statement should really be coded like this:
if (frequency[number] > high) {
high = frequency[number];
element = number;
}
size_t maxElement = 0;
for (size_t number = 0; number < SIZE; ++number)
{
/* Use ">" here, to keep the first matching frequency count, like CrazedNerd's version. */
if (frequency[number] > frequency[maxElement])
{
maxElement = number;
}
}
printf ("\n%zu was the highest occurring random number, at %i occurrences.\n\n", maxElement, frequency[maxElement]);
return 0;
Very cool, i like to know multiple ways of doing the exact same thing in a coding language, because then you can better understand how each of the pieces manipulate data.@CrazedNerd is learning C. I get that. I have written or reviewed one or two lines of C over the years. I examined CrazedNerd's code above, the version without @rmch's mods.
I saw the minor type mismatches and implied type conversions. I saw constructs that are perfectly legal in C but I would have asked for them to be re-written. I also saw constructs that are a question of style, legally allowed, but practices that could lead to issues in future C code written by the same developer. I also noted that this code will break or at least yield warnings on older machines. To be honest, I was also interested in the %zu printf conversion specification, which was unfamiliar to me.
@JasKinasis covered many of the type mismatch issues above. Pay attention to types! A type mismatch may convert as expected in some programs, but come back to "byte" you later! If I were reviewing the code in a production environment, I would not allow the arbitrary use of size_t when other types are appropriate.
Here are a few additional points:
I would have written that final loop and statements like this:
- The first loop (int count ...) has issues:
- The loop test has a hard-coded value (1000000000). That is not good practice.
- This loop will fail on old systems because it assumes that int is 4 bytes.
- Just curious: Why didn't you use size_t here?
- The general use of prefix notation for the increment operator "++X" is legal and functionally correct in this program.
- -> Be wary ... using prefix notation for the increment operator could cause unexpected bugs in "while" and "do while" loops. (With "for" loops, it doesn't matter.)
- I admit that I am not used to seeing C code written that way. I agree that it is a matter of style in this program. I am used to seeing the increment operator in postfix notation "X++" unless prefix notation is explicitly needed. If you do that, then when prefix notation is necessary in a program, it stands out. This is a matter of style preference.
- That last "for" loop is clever, but quirky.
- There is a bug: the test for frequency{1] is missing.
- The idea works, but it repeats unnecessary tests on each pass in the loop.
- If two occurrence counts match, it displays the first matching index. This is not documented anywhere.
- I would have preferred to see the printf() and return() outside the loop.
- Keep in mind that for the printf() statement, the scope of "number" is limited to the loop in CrazedNerd's version. See my suggested fix, below.
- The return() statement is in a peculiar place.
- This is legal, but not good coding practice.
- I would have used a break statement here and put the return at the end of the code.
Code:size_t maxElement = 0; for (size_t number = 0; number < SIZE; ++number) { /* Use ">" here, to keep the first matching frequency count, like CrazedNerd's version. */ if (frequency[number] > frequency[maxElement]) { maxElement = number; } } printf ("\n%zu was the highest occurring random number, at %i occurrences.\n\n", maxElement, frequency[maxElement]); return 0;
What I read in this quote may not match what I was thinking. Here is what I meant:Very cool, i like to know multiple ways of doing the exact same thing in a coding language, because then you can better understand how each of the pieces manipulate data.
For example, copying, pasting, and running that (and getting the same correct result as my version and rmch's version) has taught me that the elements in an array can be treated the way as a variable wants the ram has been allocated through declarations...your method is very efficient because you are just cycling through each of the numbers (zero through one billion) to keep matching the highest numbers and re-assinging them to maxElement.
It was, but i would recommend if you like helping people with programming, that you avoid redundancy:What I read in this quote may not match what I was thinking. Here is what I meant:
The improved efficiency in my example comes from avoiding the repeats of the early tests in that compound "if" statement where it tests frequency[number] >= frequency["index number"] && ... over and over from each pass through the final loop. By "test" I mean the "greater than" comparison.
I hope the other comments from my basic review were helpful as well.
@CrazedNerd is learning C. I get that. I have written or reviewed one or two lines of C over
the years. I examined CrazedNerd's code above, the version without @rmch's mods.
Dude, you can't think im trying to get everyone to do everything for me? Sphen said "i hope this was helpful", and i said yes but there's room for improvement.I would suggest that if there's something you don't understand, to get in to the habit of asking questions, rather than criticizing people who try to help for not spoon feeding you everything.