Converting flowchart to pseudocode

  • Thread starter Thread starter sandy.bridge
  • Start date Start date
AI Thread Summary
The discussion revolves around the challenge of converting flowcharts to pseudocode under specific classroom rules. Participants express confusion over the professor's assertion that some flowcharts cannot be represented as pseudocode, despite the general belief that all pseudocode can be illustrated by flowcharts. Key points include the limitations of flowchart rules, such as the number of arrows for actions and conditions, and the implications of these restrictions on pseudocode representation. The conversation also touches on concepts like infinite loops and the absence of certain control structures in pseudocode. Ultimately, the participants seek clarity on how these rules impact the conversion process and the professor's underlying message.
  • #51
I think the point may be that recursion can be represented on a flowchart (tieing an if back to itself) whereas it can't be represented by psuedocode unless there's a provision for defining a method/function/subroutine in the pseudocode.
 
Physics news on Phys.org
  • #52
For multi-threaded applications, an alternative to flowcharts is a data flow chart, where blocks represent queues of element of data, and connectors represent the processes that retrieve an element from one queue, optionally perform some operation on the element, then append that element to another queue. Then for each process, you can use a conventional flow chart (with an operator to allow a process to wait for the presence of one or more elements on a queue).
 
  • #53
jedishrfu said:
I think the point may be that recursion can be represented on a flowchart (tieing an if back to itself) whereas it can't be represented by psuedocode unless there's a provision for defining a method/function/subroutine in the pseudocode.
How would you distinguish between iteration and recursion with a flow chart? In the case of flowcharts or pseudocode, there would need to be some convention to describe a recursive call (as opposed to creating what would appear to be a loop back to the start of the code).
 
  • #54
Well, I emailed my professor and he essentially shot down all this work regarding this question. I do, however, have a hint: what implicit rules are there regarding performing the actions of a block, and is there a way to create a flow chart that violates one or more of these said rules.

Since blocks go from top to bottom in pseudo-code, what if we did something like this:
 

Attachments

  • unnamed7.png
    unnamed7.png
    3.9 KB · Views: 684
Last edited:
  • #55
sandy.bridge said:
Well, I emailed my professor and he essentially shot down all this work regarding this question. I do, however, have a hint: what implicit rules are there regarding performing the actions of a block, and is there a way to create a flow chart that violates one or more of these said rules.
I would assume that the actions of a block are described as text within the block, and in that case why couldn't similar text be used in pseudocode?

If the point is that a single block could have multiple arrows going out of the block, you could duplicate this in pseudocode using a goto with an arrary of labels.

update - I just noticed your figure, but already covered this case, you just need an array of labels to use with a goto. In this case one label would go to "action2", the other would go directly back to "C1?" . Both are bending the rules in the same manner.
 
  • #56
I'm starting to think that I am spending far too much time on this question.
 
  • #57
its probably going to turn out that the prof was mistaken or that there's some restriction he's not telling you about like a floating pt divide exception that causes a side-effect or that means you need another arrow into or out of the atomic action.
 
  • #58
sandy.bridge said:
I'm starting to think that I am spending far too much time on this question.
I'd wait until the professor actually gives an example of a flowchart that can't be duplicated with pseudocode, assuming you're allowed to bend the rules in the same manner for both methods.

My bend the rules extension for goto syntax:

goto {label01, label02, label03, ... }

This could be interpreted as a random branch, or it could spawn multiple threads and branch to all the labels at once. If done in a loop, then it could be continously spawning multiple threads (will assume such a system has infinite resources).
 
  • #59
Well, it's looking like I will just have to wait for the solutions. This was the last question on our assignment, but I may have to leave it empty.

"1. A block starts with a left curly brace { 2. All of the actions within a block are indented relative to its curly braces. This indenting is
consistent across the entire block.
3. A block ends with a right curly brace }
For example, the following is a block:
{
go to the front door
call out ‘‘trick-or-treat’’
}
You usually won’t just have a block by itself; blocks are a fundamental component of other
compound actions.
A block can contain any number of actions inside of it (including none at all!). In fact, a block
can contain other compound blocks inside of it. We’ll see that later.
A block has no special representation in terms of a flow chart. Blocks are used for disambiguation
in other kinds of compound actions; a flow chart has no ambiguities, since it always
uses explicit arrows to direct the flow to the next action."

This is what I have regarding blocks.
 
  • #60
Since pseudo-code is supposed to evaluate each of its actions one at a time, what if we did the following? There is nothing in the flow chart that indicates which of the atomic actions it is supposed to evaluate first, and hence we would not be able to represent it in pseudo-code unless it was actually specified.
 

Attachments

  • a1q5part1.png
    a1q5part1.png
    4.2 KB · Views: 586
  • #61
Don't leave it empty put in your best guess, you may be right (maybe the prof is searching for the answer to the conundrum himself and waiting for that one special chosen student)

You can't win if you don't play.
 
  • #62
sandy.bridge said:
Since pseudo-code is supposed to evaluate each of its actions one at a time, what if we did the following? There is nothing in the flow chart that indicates which of the atomic actions it is supposed to evaluate first, and hence we would not be able to represent it in pseudo-code unless it was actually specified.

I thought "bullets" could only have one arrow out?
 
  • #63
Yeah, you're right.
 
  • #64
In case you're interested, the solution was merely two flows meeting up at a bullet, and then going into an atomic action.
 
  • #65
sandy.bridge said:
In case you're interested, the solution was merely two flows meeting up at a bullet, and then going into an atomic action.

:confused: But with only one START allowed, where does the second flow come from? That's what we were trying so hard to gimmick up with the phantom threads created by the dangling decision blocks... Hmph.
 
  • #66
sandy.bridge said:
In case you're interested, the solution was merely two flows meeting up at a bullet, and then going into an atomic action.
Two flows or two paths, of which only one can be taken at a time? If it's two paths, then this is the same as pseudocode containing two or more branches to the same label.
 
Last edited:
  • #67
sandy.bridge said:
In case you're interested, the solution was merely two flows meeting up at a bullet, and then going into an atomic action.

Professorial fail. That's easy to represent in pseudocode and a common requirement.

I don't suppose you have a diagram of this so-called impossible flowchart.
 
  • #68
Here:
 

Attachments

  • q5_soln2.png
    q5_soln2.png
    4.8 KB · Views: 730
  • #69
But that's trivially implemented in any pseudo code that isn't deliberately hobbled by fanatical style rules.
 
  • #70
FirstTest: If not wantBanana then goto SecondTest
selectFruitFromBunch
Enjoy: peelAndEatFruit
goto FirstTest
SecondTest: if wantOrange then goto Enjoy
Stop
 
Back
Top