1. CSCE 489- Problem Solving Programming Strategies Spring 2018
Academic Honesty
CSCE 489- Problem Solving Programming Strategies
Spring 2018

2. Academic Honesty
As a special topics course, you should be taking this to improve your own skills. Cheating counteracts the reason you are taking this class!
Since problems are public, it may be possible to find a public solution to the problem. THIS IS NOT OK TO LOOK AT!!!
If you are caught copying code or having unallowed collaboration, you should expect a very strong penalty (no less than an F*) in the course. Since it is in some ways “easier” to cheat, a higher-than average penalty should be expected if it does happen.

3. So, what is/is not allowed?
If you have not solved the problem, you probably should not look at someone else’s code.
If you have solved the problem, you should be careful about the level of discussion you have with others.
You can always discuss with others what a question is asking – making sure you understand what is being asked in the question.
You generally should not discuss the actual way to solve the problem.
After the deadline (in the “upsolving” week afterward) feel free to discuss the problem, read descriptions of solutions, etc.
But, you still should not look at code. You get partial credit for the upsolving because it shows you can still translate ideas into code, even if you could not come up with the solution!
You may use some common sense for getting help from others with small debugging issues, syntax problems, language feature issues, etc.

4. The Goal
The goal is for you to determine how to solve a problem (what the right algorithm/approach is), implement it, and test it.
Things that interfere with that are not OK. You preventing others from coming up with their own solution, or you getting the solution from others, interferes with that.
If you can’t come up with the solution yourself – that is what the upsolving period is for.
You need to use some common sense. The idea is not to prevent all discussion of problems

5. If in doubt Ask the instructor or teaching assistant!
Better to err on the side of caution.
Don’t ask others to put themselves in compromising situations!

6. Examples
To (hopefully) clarify what is and is not OK, I will give a lot of examples here to illustrate what is and is not OK.

7. Example conversations (OK or not?)
“We’re supposed to read in coordinates. Do we need to handle floating point numbers or just integers?”
“I just read in integers and it worked fine.”

8. Example conversations (OK or not?)
“We’re supposed to read in coordinates. Do we need to handle floating point numbers or just integers?”
“I just read in integers and it worked fine.”
Yes, this is OK. It is part of understanding the problem itself.
Now, hopefully the problem specified this, so a better answer might be “read the question!”

9. Example conversations (OK or not?)
“Is this one we’re supposed to use a dynamic programming approach for, or does a greedy approach work?”
“You need to use a dynamic programming approach. The greedy one won’t handle all the cases.”

10. Example conversations (OK or not?)
“Is this one we’re supposed to use a dynamic programming approach for, or does a greedy approach work?”
“You need to use a dynamic programming approach. The greedy one won’t handle all the cases.”
Not OK. This goes to how to solve a problem, rather than understanding what the problem is asking.

11. Example conversations (OK or not?)
“Can you look at my code and see why I’m not getting the total number correct?”
“You’re double-counting some cases – you need to make sure you’re counting each solution only once.”

12. Example conversations (OK or not?)
“Can you look at my code and see why I’m not getting the total number correct?”
“You’re double-counting some cases – you need to make sure you’re counting each solution only once.”
Probably not OK. This seems to be asking someone to look at your code and tell you if your solution method is right or not; the response is dealing with how to solve the problem.
The response would be OK during the upsolve period if the person responding had solved the problem already.

13. Example conversations (OK or not?)
“Can you look at my code to tell me why this angle computation isn’t working?”
“It looks like you need to convert from degrees to radians.”

14. Example conversations (OK or not?)
“Can you look at my code to tell me why this angle computation isn’t working?”
“It looks like you need to convert from degrees to radians.”
Probably OK, although looking at code is not a great idea. Here, the problem is one dealing with a language feature, not actually a solution to the program.
If the answer were “You don’t want to compute the angle – just use the Pythagorean Theorem.” that would not be appropriate, except during the upsolve period.

15. Example conversations (OK or not?)
“How do I check for end of input when I don’t know how many lines to read?”
“If you try to read a line, then you can check whether cin.eof() is true to see if you’ve read to the end of input.”

16. Example conversations (OK or not?)
“How do I check for end of input when I don’t know how many lines to read?”
“If you try to read a line, then you can check whether cin.eof() is true to see if you’ve read to the end of input.”
This is OK – it is a more general language issue. Although it might be needed for the problem, it’s not the point of the problem.

17. Example conversations (OK or not?)
“I’m trying to create a pair of pairs, but keep getting a compile error. Do you know what the problem is?”
“You need to have an extra space in between your closing brackets, so that it’s clear you’re ending a template, not writing a steam operator.”

18. Example conversations (OK or not?)
“I’m trying to create a pair of pairs, but keep getting a compile error. Do you know what the problem is?”
“You need to have an extra space in between your closing brackets, so that it’s clear you’re ending a template, not writing a steam operator.”
Yes, this is OK – it has to do with basic syntax and how to use language features.
pair<pair<int, int>, pair<int, int>>
pair<pair<int, int>, pair<int, int> >

19. Example conversations (OK or not?)
“Hey – I solved problem C. That was tricky.”
“I’ve been trying but keep failing on test case 4.”
“Oh, that got me, too. Make sure you are handling the case when the input is 0.”

20. Example conversations (OK or not?)
“Hey – I solved problem C. That was tricky.”
“I’ve been trying but keep failing on test case 4.”
“Oh, that got me, too. Make sure you are handling the case when the input is 0.”
Not OK. This is going to the specific test cases that can cause things to fail.
The best response would be to stop at “Oh, that got me too.”
A borderline answer would be “Make sure you’re handling edge cases.”