HERE is what i do hate the most about "coding"...

[CrazedNerd]

The fix is to change %zu to %d in your printf statement.

Yeah i think you're right ill try it later.

 

[CrazedNerd]

Yup 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).

Yeah i actually don't think it matters...im just using a basic gcc compiler and it never whines about %zu/size_t

Anyways, i changed what @JasKinasis told me to, then made another subtle difference...

printf ("\n%zu was the highest occurring random number, at %i occurrences.\n", element, high);

(it's supposed to be "element,high")

and voila, you hacked it and now it works exactly the same, except now it doesn't have that lame too-long if statement

however, i'm a little confused by what comes after the ternary operator...

element = number : 666

Is this just for printing the number again if it happened to be 666? Or, 666 over-riding whatever ther highest number happens to be...since it is rather a religiously important number and pretty far out and metal? I'll be testing it in a moment (adding removing things to see what you did), i'm gonna go do a victory dance. Isn't that cool, all i did was get you to something for me and help and now i feel a sense of accomplishment! I am the most 'lite hacker on the cyberweb!

 

[rmch]

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;
}

 

[CrazedNerd]

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;
}

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)

 

[sphen]

@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:

• 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.

I would have written that final loop and statements like this:

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;

 

[Mike13Foxtrot]

What is needed is a human interface language compiler. Like, you type what you want it to do and it is interpreted into machine lang. I guess AI could be the link but.... if we didn't have all the different codes languages we wouldn't need all the nerds.

Too many hey this might work but to do so I had to recompile the Kernel. I had to add this, remove that. And all that and it sort of works.

Got started into C in the 90's, then realized I am better at hardware, and setting up things, and get the programmers to do their thing.

 

[CrazedNerd]

@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:

• 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.

I would have written that final loop and statements like this:

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.

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.

 

[sphen]

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.

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]

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.

It was, but i would recommend if you like helping people with programming, that you avoid redundancy:

@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.

It was already mentioned that I am learning C...i really wished i was experienced enough that i could write programs that people would find useful, but it's pretty clear still that this will be a very slow process, and i'm obviously going to need to be working on python because that's what practically all programmers learn anyway. Also, i will need to learn C++. It's very clear to me that it's going to take me years before i have any respect or professional cred within online programming communities. I think it would nice to make some real life friends with programmers, but that is just hopeless because I'm too different from the norm. Plus, i have degenerative disc disease and i don't want to make friends with people in real life who will say stupid shit like "YOU DON'T LIKE SITTING IN A CHAIR ALL THE TIME?! WHY NOT! EVERYBODY DOES IT, LETS SPEND ALL DAY SITTING IN A CHAIR!"

And, also, i would say this a general rule for every subject matter, if you say something is good or bad, you always explain in more detail what you mean. In a way, i don't really care because this is not software that anyone else will use besides me, but i there isn't even the slightest bit of chance that will even be able to make software for other people without understanding why "hard coding values is bad".

 

[MattWinter]

Part of programming is continuous learning. If you're writing an application to automate business tasks, you need to learn business tasks. If you're writing software to do physics modeling, you need to learn physics. 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.

Hard coding a number is bad because it makes the code less maintainable. If you want to generate a random number from 1 to 10, you might be tempted to hard code 10. But what if you now want to generate rolls of a non-standard die (think Dungeons & Dragons dice). How many places in your code do you need to update 10 to 20 or 12 or 6? How can you be sure you didn't miss one? Setting a variable or using #define can make it easy by providing a single place to make the update.

Also, I know you have issues with formal education, but it really helps to fill in all the areas a good programmer would need to know. I'm thinking about my undergrad and thr courses I took: Intro to programming, programming 1, programming 2, data structures and algorithms, assembly language, computer architecture, operating systems, object oriented methods, Unix systems, software design, systems programming, GUI design, database systems, Discrete mathematics, linear algebra...I'm sure I'm forgetting some, and that's not counting the additional math and science requirements that go along with a science degree.

I say this not to discourage you, but rather to help set expectations. No one is going to be able to sit down with a book on C and learn it in a week, a month, or even a year, and expect to be an expert.

 

[CrazedNerd]

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.

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'm definetly not enjoying this forum anymore and goodbye.

 

[wizardfromoz]

Just a heads up that the Member is leaving us and I am locking this Thread.

I have let him know that his contributions to our community and the forum have been welcome, and that he is always welcome back. I wish him well in his future endeavours and learning.

Chris Turner
wizardfromoz