can someone show me how do you solve the problem with paper and pencil?

You don't consider the flowchart in post #26 to be "paper and pencil"?

The algorithm isn't complicated. You can determine the results by passing through the array of numbers once. I don't know why sorting is being mentioned. I don't think it's necessary.

 

most of people suggest advice to solve problem with paper and pencil. I have tried my best attempt to solve problem if possible can someone show me how do you solve the problem with paper and pencil?

Isn't that the title of this thread? "Flowchart"

"Pencil and paper" is perhaps an outdated colloquialism when applied to work on a computer. The algorithm I used in post #31 occurred to me as I was doing something else (routing a PCB). When I laid down, it became clearer, so I got up, scribbled it on paper, then wrote the code. That is why the original timestamp is 0311 (local time). The algorithm is just steps 4 and 5.

I consider it a type of sort, but one does not need to use a number of registers equal to the largest number. For example, if the largest number is 1023, you only need a maximum of 128 registers devoted to the question. There are other games one could play with packing.

Every discussion I can recall on the subject of "flowchart" seems to lose sight of using a flowchart as a tool to solve a problem versus the product of solving a problem. Does the code you wrote in post #37 work to give the answer?

 

You don't consider the flowchart in post #26 to be "paper and pencil"?

The algorithm isn't complicated. You can determine the results by passing through the array of numbers once. I don't know why sorting is being mentioned. I don't think it's necessary.

This step looks fuzzy to me:


Can you give more detail of how you keep track of whether a number has been seen before or not

 

Can you give more detail of how you keep track of whether a number has been seen before or not

It's an implementation detail that I chose to omit so the OP could see that starting to sling code from the beginning can hinder solving the problem.

There are many ways to do it. I did a solution in Perl that used a hash (associative array) to do it. It was referenced in post #9.

 

Ok. Here is another solution that is not too inefficient for small arrays.

Compare x(2) with x(1).
Compare x(3) with x(1) to x(2).
:
:
Compare x(i) with x(1) to x(i-1)
:
:
Compare x(n) with x(1) to x(n-1)

If n = 200, it will require 19,900 tests.

 

Can you flesh this out?
View attachment 203309

can you post clear picture and it would be much help if you can mention values on box. Would it be beneficial to create a table before a flow chart ?

 

can you post clear picture and it would be much help if you can mention values on box.

The whole point of a flow chart is that it helps you develop an algorithm without needing actual values.

Would it be beneficial to create a table before a flow chart ?

That defeats the purpose of the flow chart. When I first started learning how to program, the first step was to understand the problem, and the flow chart was used to develop the algorithm. A flow chart isn't necessary if you can keep details straight without one.

 

If n = 200, it will require 19,900 tests.

Plus the housekeeping.

With indirect addressing, one needs n(movlw + call + return + loop(=5)) +1 (branch to answer) = 1601 instructions and <=200 tests with most housekeeping included. Of course, 200 registers are needed for the form presented.

 

Here is my code

#include <stdio.h>

int main()
{
    int data[11] = {5, 3, 7, 1, 6, 3, 9, 12 , 21, 13, 16};
 
    for ( int  sizeOfData = 0;  sizeOfData <11;  sizeOfData++)
          printf( "data = %d \n", data[ sizeOfData]);

    return 0;
}

data = 5
data = 3
data = 7
data = 1
data = 6
data = 3
data = 9
data = 12
data = 21
data = 13
data = 16

You don't want to hardcode your loop so that it only works with an array that has exactly 11 elements in it.
You have a variable, sizeOfData, that is initialized with the size of the array. You need to use THAT variable in the place where you have hardcoded the 11 and use a different index variable.

Assuming you make that change, can you draw a flow chart that matches this code? Just worry about the for() loop, assume that the data is already in the array when you reach the start symbol and that the return is taken care of after the stop symbol.

Once you've done that, can you modify the flow chart so that one each pass of the loop you make another pass through the array and print out all possible pairs of numbers. So you output should look something like:

(5,5)
(5,3)
(5,7)
...
(5,13)
(5,16)
(3,5)
(3,3)
(3,7)
...
(16,16)

There should be a total of 121 lines.

Work with me, here, and we will get to a solution to the problem (not a good solution, but a solution that works) very quickly.

 

This is an interesting problem and one that emphasizes the importance of employing a proper problem solving strategy in the first place.

As I have always maintained, writing code is the last thing you want to do. You need to arrive at an algorithm or strategy first. Then you can draw a flowchart. Pseudocode serves the same purpose as a flowchart. You may create either or both as an exercise.

If the range of numbers and the size of the array are low then sorting the array is the first strategy that comes to mind. However, if the size of the array is very large then sorting is very inefficient.

The solution I would choose is one called hashing which is a technique used to create a table of variable names by a code compiler. This is very similar to how dictionary searches are performed.

Plus the housekeeping.

With indirect addressing, one needs n(movlw + call + return + loop(=5)) +1 (branch to answer) = 1601 and most housekeeping included. Of course, 200 registers are needed for the form presented.

It's an implementation detail that I chose to omit so the OP could see that starting to sling code from the beginning can hinder solving the problem.

There are many ways to do it. I did a solution in Perl that used a hash (associative array) to do it. It was referenced in post #9.

Guys, the TS is struggling with getting a single loop that prints out the values in the array coded well. Don't you think that throwing around sorting and hash functions and pointers and indirect addressing and associative might be just a bit premature?

 

The whole point of a flow chart is that it helps you develop an algorithm without needing actual values.
That defeats the purpose of the flow chart. When I first started learning how to program, the first step was to understand the problem, and the flow chart was used to develop the algorithm. A flow chart isn't necessary if you can keep details straight without one.

Working through a toy problem by hand is a very common technique that is used as a bridge between understanding the problem and designing the algorithm.

 

Guys, the TS is struggling with getting a single loop that prints out the values in the array coded well. Don't you think that throwing around sorting and hash functions and pointers and indirect addressing might be just a bit premature?

Hash functions, yes. Sorting and pointers no. Pointers are basic in all languages, right? At least in Assembly and C they seem to be.

 

If the TS wants to learn how to formulate an algorithm using a flowchart he should begin with something like a sort algorithm.

 

Hash functions, yes. Sorting and pointers no. Pointers are very basic in all languages, right? At least in Assembly and C they seem to be.

I think implementation details would confuse the OP.

 

If the TS wants to learn how to formulate an algorithm using a flowchart he should begin with something like a sort algorithm.

How is sorting helping to solve the problem? I don't see it as being necessary. The code example I posted will produce the solution without sorting. I sorted the results, but that wasn't a requirement for this problem or the original problem.

The OP wants to learn how to solve the stated problem; not count how many iterations, registers, or resources it will take.

 

I think implementation details would confuse the OP.

We have very different perspectives. The TS came here asking a question about how to solve a problem. Some talk about the problem. After 30 responses, I prefer to talk about a solution.

 

After 30 responses, I prefer to talk about a solution.

I gave him a link to a solution in post #9 with a caveat that he should only look at it when he was ready.

 

Hash functions, yes. Sorting and pointers no. Pointers are basic in all languages, right? At least in Assembly and C they seem to be.

And they are almost never even mentioned in a C course or text until well into it. I've just looked at several C textbooks I've got and every single one of them covers arrays before pointers. As for sorting, most of them talk about just a single sorting algorithm, usually bubble sort, near the end of the chapter on arrays. Before that are problems that are readily solvable by simply scanning the array. The focus is on gaining familiarity with working with arrays, not on developing and implementing higher-level algorithms. Those come much later in the text. The TS very much appears to be at the stage of learning how to work with arrays.

 

Microchip's and every other tutorial I have seen on Assembly use indirect addressing very early. Even Microchip's early datasheets showed how to erase a block of RAM with indirect addressing. I have also seen tutorials on C that introduce pointers. In my mind, there is hardly any difference between a jump from one part of the code to another (e.g., goto or call) and indirect addressing. FSR's are simply labels/counters for RAM instead of program in that view.

 

TS has already done simple iteration such as find floor and ceiling in an array.
TS is having problems with nested loops. He selected a problem that is a bit beyond his capabilities.
TS is having problems with problem solving. Give TS a problem that he can handle himself and extend his capabilities and confidence.

How about multiply two 8-bit unsigned integers without using a multiply function?