Print SFG

Description of issue:

The program should be able to print a SFG in a way so that is clear to the user that the data printed is a SFG. The representation should contain any data relevant to the evaluation and representation of the SFG.

Linked Requirements:

( 31 )

Potential Issues:

The data to be printed is currently unknown and might depend on previous implementation of #12 (closed).

Blockers:

( #12 (closed) )

Issue Requirements:

1. Given a valid SFG, then the program should be able to represent and present the SFG in a human readable and clear way to the user in text-form.
2. This print should not in any shape modify the SFG.

Comment:

For more details on data needed please discuss in the issue. Please document the data that is decided to be printed in this issue.

added 1 deleted label

mentioned in issue #26 (closed)

mentioned in issue #31 (closed)

changed time estimate to 5h

added 1 deleted label

added 1 deleted label

assigned to @adaja901

Example of a graph Expected output:

id: add, name: -, input: [s1, s2], output: [s5]

id: add, name: -, input: [s3, s4], output: [s6]

id: add, name: -, input: [s1, s2], output: [s7]

1. Is the expected output related to the example graph? If so, then the expected output should be:

• id: add, name: add1, input [s1,s2], output: [s5]
• id: add, name: add2, input [s3,s4], output: [s6]
• id: add, name: add3, input [s5,s6], output: [s7]

2. Why are the input operations not in the expected output? They can be printed:

• id: in, name: in1, input [], output: [s1]
• id: in, name: in2, input [], output: [s2]
• id: in, name: in3, input [], output: [s3]
• id: in, name: in4, input [], output: [s4]

As a developer I want be able to print out name for operations and id for signals and operations.

As a developer I want be able to print which signals are input and which signals are output for a operation.

As a developer I want to be able to print time-delays.

As a developer I want be able to print what coefficient a const operations has.

Please review @jacwa448 or @arvwe160

added 1 deleted label and removed 1 deleted label

LGTM, but how should the info be presented to the user, in tables or in some sort of visualization like ->Addition->...

I thought it should be presented as the first comment in this issue. In one row one operation is presented with it's name, id, the input signals and output signals. Then the next row next operation should be presented in the same way.

Sure maybe throw up an example for how this would look like for a general SFG

As a developer I want be able to print an expected output for an addition as:

id: add, name: -, input: [s1, s2], output: [s5]

Please review my new use-case @jacwa448

Fine for me, but maybe get a second opinion on it, @anglo547 what do you think?

changed milestone to %Period 1 Kanban

added 1h of time spent at 2020-04-06

Looks good, but I have some thoughts:

• The name of the operation might be empty in the general case, so perhaps id should be printed before name in the ordering?
• The way id's are generated now the usually look like "add1", while the name can be anything.
• Inputs aren't signals but they are operations, so in your example SFG then there should be boxes before the "in-signals" that are input operations and there should be signals with ids like "s1", "s2", "s3", "s4". The same is the case for Outputs.
• Since Inputs and Outputs also are operations then perhaps they should be printed as well? Or maybe not, @ivaha717 mentioned that they should be hidden, anyway this should also be decided.
• When you print which signals that are connected as input, outputs, then you mean the id's for signals connected right?
• I also think that the output perhaps should be changed slightly for better readability, for example: "name: add1, id: 1, input: [in1, in2], output: [s5]" with comma separation and '[]' for multiple values or "name: add1 id: 1 input: in1, in2 output: s5" with a couple of spaces of spacing between parameters (looks like markdown stripped the extra spaces before rendering... well maybe you get what I mean), what do you think?
• Also I was wondering if the printing of the different operations will be done in a specific order or not? For the user it's better if operations close to each other are printed after one another but might be hard to implement in a clean way.

• I agree id should come first but should it print id or typename. I think it will be to much if we print all id, typename and name.
• Yes, can change that.
• Will change that.
• So a input box should only be a box with an output and vice versa for output?
• Yes, the input and output for a operations is the id for the signals
• There is now three spaces between the parametres but I think, as you suggested, that it will be more readable with brackets and commma separations
• I think it´s hard to implement but I think it should be some kind of topological ordering

• I don't think typename is necessary. Just printing id and name should be sufficient.
• 
• 
• Yes, but as mentioned they probably shouldn'y be included in the printing anyway.
• 
• 
• A correct topological order isn't really possible since there can be feedback loops, but it could be done so that the last connection that establishes the feedback is "ignored", and then we can have an almost perfect topological order.

For the last point, should that be a use-case?

Perhaps... But it's not really a priority so just printing via a normal traversal should be sufficient for now I think. However I'm not sure if a DFS or BFS traversal would be better. With a DFS traversal then you would get a good idea of how one input maps to one output, but with BFS you would get a better idea of how operations close to each other are connected. I think DFS implementation would be better, but what do you think?

I get what you think but wouldn't it exist a list of all operations for a sfg? In that case we can get all information from that list and just print it as the id order. The disadvantages will be if an operation has added at a later moment but the most time that will not happend.

I don't think that SFG currently stores a list with the operations currently, I think it only stores a dictionary that maps id to operation and a dictionary that maps name to a list of operations with that name.

Also I see that in your example output you print "id: 1" when id should be "add1". Typename is a string that defines what type of operation it is, so currently it's just "add". Otherwise it looks good.

So I can't use the SFG dictionary to print the information? Because that would be an easier way

You could iterate over the dictionary, but then the printing of the outputs would be in "random" order as a dictionary isn't ordered in any specific way. So traversing with DFS and then printing would probably be optimal.

Okej

As a developer I want to print the operations in the topological order of the SGF.

I discussed this with @ivaha717 and he said the he could make it so that SFG saves a list of the operations in correct topological order, so that you could just iterate over them when printing. Not sure when it would be implemented, but if when it's implemented then it would be better to iterate over that list than to traverse with DFS.

LGTM, user-stories are good now!

added 1 deleted label and removed 1 deleted label

added Needs testing label and removed 1 deleted label

added Feature development label and removed Needs testing label

Writing tests done, start to develop

I have writing the print function, have an error in code to fix before trying to test the function

mentioned in issue #62 (closed)

Implementation done but struggle with a test. Could need som help with the assert in test_print_one_addition

It fails since you are not actually returning anything from the sfg method just printing. It might also be a good idea to use the actual toString method in python by overriding the __str__ method, then we will just need to do print(sfg) instead of calling the method.

Thanks, I will look into it later today.

created merge request !20 (closed) to address this issue

mentioned in merge request !20 (closed)

added Needs review label and removed Feature development label

mentioned in merge request !21 (merged)

added 1d 7h 30m of time spent at 2020-04-13

added 1 deleted label and removed Needs review label

closed

removed 1 deleted label

added 1 deleted label