Trying to make this counter output something different

Right now, I am currently running through dozens and dozens of example programs to try to give myself a better understanding of loops and whatnot. Now I am fine with making loops work fine for the most part, however what I am trying to do is now change this program to output something different. Right now the output (shown at the end, first output, comes out how the program intends. However I am trying to alter it to output this instead (shown at end, second output). I'v managed to get it to output various different ways, but I Can't seem to get it to output how it's supposed to. Any enlightenment to my current situation would be loved.

Code:

---

#include <stdio.h>

int main(void)

{

    const int ROWS = 6;

    const int CHARS = 6;

    int row;

    char ch;



    for (row = 0; row < ROWS; row++)

    {

        for (ch = ('A' + row);  ch < ('A' + CHARS); ch++)

            printf("%c", ch);

        printf("\n");

    }


    getchar();
    return 0;

}

---

Proper output::

ABCDEF
BCDEF
CDEF
DEF
EF
F

New intended output::

ABCDEF
ABCDE
ABCD
ABC
AB
A

print A + column instead of row + a + column. Just look at the output and put it into actual words what is happening.

Quzah.

I don't understand what you mean. When I visually look at it, I can tell that it is for every count, it is starting from A, then moving one over then doing the loop again. Then it uses the outer counter to change the inner loop, so instead of starting at A, it starts at B and counts one over again.

But looking at the program, I can't visually figure out how I would change it to instead of start from A, counter over, start at B, etc, rather than start at F, count down, remove a character, and inevitably go through the same thing except in reverse.

ABCDEF
ABCDE
ABCD
ABC
AB
A

First row, first column, is an A.
First row, second column is a B.
...

Second row, first column, is an A.
...

Each time, you have less per row, but you start at the same spot on each row. That means you don't need a different counter to see where you start on each row, you just start at the same spot per row.


Quzah.

well I know having ch = 'A' stops the program from counting one ahead and then doing it. However, when I try to have the program reduce the last character, my command prompt shows me billions of random non-alpha ASCII characters then crashes my DEV C++ because the counter goes negative and crashes. I'm not entirely sure what I need to do to make it count from the last character and back down.

Study this code and logic:

Code:

---

#include <stdio.h>
#define ROW 5

int main() {
  int i, j;
  char ch='A';
  printf("\n\n");

This is an example of the logic that will do it:

  start for loop: i equals ROW, stop at i equals 0, decrement i
    start for loop: j equals zero, j less than i, increment j
        print the char ch+j
    end inside for loop
    print '\n'
  end outside for loop

  printf("\n\n\t\t\t    press enter when ready");
  (void) getchar();
  return 0;
}

---

Make ROW 6 if you want F.

I tried taking that and trying to make it work with my program, however the only output was blank when I tried. I still don't understand enough about how characters like this work to fully understand what I can do with it. Right now i'm probably even further behind than when I started.

I decided to use what you gave me as to not complicate and confuse myself. This is what i'v got, right track? Because so far all outputs are nothing. ( I may have a bad printf statement, not sure)

Code:

---

#include <stdio.h>
#define ROW 5

int main() {
  int i, j;
  char ch='A';
  printf("\n\n");

  for (i = ROW; i = 0; i--)
  {
      for (j = 0; j < i; j++)
    printf ("%c", ch + j);
  }
   

  printf("\n\n\t\t\t    press enter when ready");
  (void) getchar();
  return 0;
}

---

Quote:

---

Originally Posted by NinjaFish

I tried taking that and trying to make it work with my program, however the only output was blank when I tried.

---

Ummmm... when you've been doing your programming exercises have you been typing in the code yourself, or have you been cut/paste copying it from someplace?

The reason I ask has to do with how people learn... for example, we learn spelling by writing, we learn language by speaking, that is, we mostly learn by doing. Having things done for us defeats the mechanism.

My suggestion is that you start with a blank screen, set all other code aside, and come at this problem from a fresh perspective... But 100% of your own creation... By all means have your C library documentation handy and be eager to look things up in the process of figuring it out (many, many years into this and I still look stuff up all the time).

Just make sure it's all yours in the end... What you learn will stay with you and you will understand it far better, when you're done.

It's not an especially difficult problem --you aren't writing a missile guidence system-- so this should be a good exercise to help you get the basics down pat.

The last code you posted is very close... Think in baby steps about the sequence of events you have to create. Remember that when programming you are dealing with a totally obedient idiot that's going to do exactly what you say and nothing else... you have to tell it everything and in the right order... You'll get it....

Forget about characters. Replace letters with numbers. Make it:

123456
12345
1234
123
12
1

If you can figure that out, you can figure out the rest.


Quzah.

Quote:

---

Originally Posted by CommonTater

Ummmm... when you've been doing your programming exercises have you been typing in the code yourself, or have you been cut/paste copying it from someplace?

The reason I ask has to do with how people learn... for example, we learn spelling by writing, we learn language by speaking, that is, we mostly learn by doing. Having things done for us defeats the mechanism.

My suggestion is that you start with a blank screen, set all other code aside, and come at this problem from a fresh perspective... But 100% of your own creation... By all means have your C library documentation handy and be eager to look things up in the process of figuring it out (many, many years into this and I still look stuff up all the time).

Just make sure it's all yours in the end... What you learn will stay with you and you will understand it far better, when you're done.

It's not an especially difficult problem --you aren't writing a missile guidence system-- so this should be a good exercise to help you get the basics down pat.

The last code you posted is very close... Think in baby steps about the sequence of events you have to create. Remember that when programming you are dealing with a totally obedient idiot that's going to do exactly what you say and nothing else... you have to tell it everything and in the right order... You'll get it....

---

As I said, i'v been working from examples. That above code is just a slightly modified example from the book. And yes i'v written it out. Multiple times. As a matter of fact, im heading on.. 4 and a half hours of sitting on this question, trying to work it out logically and make changes. However, I originally did C++ in my college course taught by a rather anal man whom expected perfection and the best possible professionally written program in a beginner course, which never helped. Since I am learning C, I am having a bit of a hard time adapting to the small syntax change C++ added, so C is not only being difficult, but I also have no knowledge, whatsoever, of characters in programming. The closest I ever even had to know was string, which isn't char.

Also, my learning comes from two things -- visual reference // self-understanding of how the code works. Unfortunately, the text and code I'v been only outlines how the program works, and gives no way of how a negative counter can work with characters. And up until this example, everything has been basic numerics and printf statements.

You were VERY close. Replace the red = with > and you're done.

Code:

---

#include <stdio.h>
#define ROW 5

int main() {
  int i, j;
  char ch='A';
  printf("\n\n");

  for (i = ROW; i = 0; i--)    // replace = with >
  {
      for (j = 0; j < i; j++)
        printf ("%c", ch + j);
     
      printf("\n");
  }
  printf("\n\n\t\t\t    press enter when ready");
  (void) getchar();
  return 0;
}

---

Good job, and a belated welcome to the forum, NinjaFish! :D

Quote:

---

Originally Posted by NinjaFish

As I said, i'v been working from examples. That above code is just a slightly modified example from the book. And yes i'v written it out. Multiple times. As a matter of fact, im heading on.. 4 and a half hours of sitting on this question, trying to work it out logically and make changes. However, I originally did C++ in my college course taught by a rather anal man whom expected perfection and the best possible professionally written program in a beginner course, which never helped. Since I am learning C, I am having a bit of a hard time adapting to the small syntax change C++ added, so C is not only being difficult, but I also have no knowledge, whatsoever, of characters in programming. The closest I ever even had to know was string, which isn't char.

Also, my learning comes from two things -- visual reference // self-understanding of how the code works. Unfortunately, the text and code I'v been only outlines how the program works, and gives no way of how a negative counter can work with characters. And up until this example, everything has been basic numerics and printf statements.

---

Well, if you worked in C++ then you already know most of this stuff... you should know how for() loops work, about basic if/else structures, while() and do/while... you should already have all that stuff worked out or you'd never get a C++ program any bigger than "hello world" to work.

C is a different language but not SO different you shouldn't be able to adapt rather easily...

Take my word for it... staring at code teaches you nothing (as it would appear you are now discovering)... writing code, reading code... fixing broken code... now that's how you learn.

Quote:

---

Originally Posted by Adak

You were VERY close. Replace the red = with > and you're done.

Code:

---

#include <stdio.h>
#define ROW 5

int main() {
  int i, j;
  char ch='A';
  printf("\n\n");

  for (i = ROW; i = 0; i--)    // replace = with >
  {
      for (j = 0; j < i; j++)
        printf ("%c", ch + j);
     
      printf("\n");
  }
  printf("\n\n\t\t\t    press enter when ready");
  (void) getchar();
  return 0;
}

---

---

Ah. Thats something I would never of found. Well, maybe after a few hours when I gave up and said "Im going to try replacing every operator with another til it works".

Thanks alot :)

And thank you to the man who posted up the code with the text to help me get a feel for how it would go. Gave me exactly the visual reference I needed without telling me how it would go. Now i'll re-write the code out so I understand it better and put it into how I format and write my code. Thanks a bunch.

Quote:

---

Originally Posted by CommonTater

Well, if you worked in C++ then you already know most of this stuff... you should know how for() loops work, about basic if/else structures, while() and do/while... you should already have all that stuff worked out or you'd never get a C++ program any bigger than "hello world" to work.

C is a different language but not SO different you shouldn't be able to adapt rather easily...

Take my word for it... staring at code teaches you nothing (as it would appear you are now discovering)... writing code, reading code... fixing broken code... now that's how you learn.

---

Agree'd however. While syntax and such are the same, stuff like char (if it's even in C++) I was never taught. As a matter of fact, most of the stuff he taught us was absolutely garbage and never went past a few of the variable types. And again, I am just learning. However I don't have the knowledge yet to be able to read a code and figure out EVERYTHING wrong with it. My mind skips over simple mistakes, and pure logical thinking I am not to good with. I find it hard to break down each step. I can do it, however I do tend to miss stuff and get confused. I never just stare at code either. I always read it, figure out what is happening step by step. However, for me I didn't fully understand how it was working. I had an idea, but I didn't clue in for awhile on how the outter loop was affecting the inner loop. With the visual reference (which I learn better using), it made it easier to see everything and how each step went with the next.

Quote:

---

Thanks alot

---

You're welcome! :D

Quote:

---

And thank you to the man who posted up the code with the text to help me get a feel for how it would go. Gave me exactly the visual reference I needed without telling me how it would go. Now i'll re-write the code out so I understand it better and put it into how I format and write my code. Thanks a bunch.

---

And you're welcome, again! :D :D

What I did was write a little program to test this, then I thought, "no, that's too explicit", so I posted up the program, but cut out the heart of it, and replaced it with the exact pseudo code for it.

It wouldn't have been exactly right, otherwise imo.

We are just too good to noobs, I swear! :p :p

Quote:

---

Originally Posted by NinjaFish

Agree'd however. While syntax and such are the same, stuff like char (if it's even in C++) I was never taught. As a matter of fact, most of the stuff he taught us was absolutely garbage and never went past a few of the variable types. And again, I am just learning. However I don't have the knowledge yet to be able to read a code and figure out EVERYTHING wrong with it. My mind skips over simple mistakes, and pure logical thinking I am not to good with. I find it hard to break down each step. I can do it, however I do tend to miss stuff and get confused. I never just stare at code either. I always read it, figure out what is happening step by step. However, for me I didn't fully understand how it was working. I had an idea, but I didn't clue in for awhile on how the outter loop was affecting the inner loop. With the visual reference (which I learn better using), it made it easier to see everything and how each step went with the next.

---

I understand your conundrum... I really do since in some ways I share it. (My long term memory tends to be anechdotal in nature, which doesn't help for remembering things like names, dates, etc.)

However; it is the step by step, analytical thinking that forms the heart and sould of a programmer's craft. As a friend of mine once pointed out, as I annoyed the hell out of him with minute details about a problem in his computer... "You programmer types think in such tiny blobs..." and he's right... the smaller the blobs the better! The real skill comes from understanding each small bit in isolation then being able to apply it to the overall outcome.