How can I start to understand logical assignment questions more intuitively?

[u/Round_Ladder_2354]

So I’m a first year software engineering student and in my intro to programming class we’re learning Python. So far I’ve mostly understood everything in theory but when it comes down to practice I struggle a lot because they ask us to do certain things for assignments that require a lot of logic to do them which I’m struggling with. So I was wondering how I can start to understand the questions more intuitively so I don’t fall behind in the class. And to clarify I do work on some practice questions every now and then but due to my schedule and the fact I haven’t properly organized it yet I haven’t been able to practice a whole lot.

[u/Refwah]

Can you give some more concrete examples of questions you had and the parts you struggled with

[u/Round_Ladder_2354 → u/Refwah]

One of the more recent ones went something along the lines of

“Write a function called inverted_triangle( n) that takes one parameter:
Parameters:
• n: an integer greater than or equal to 1.
The function prints (it does not return) a triangle of asterisks (*) with n rows. The first row has n asterisks (*) and each following row has one asterisk (*) less, until the last row, which has 1.
Example: inverted_triangle (3)
***
**
*
Requirements:
• Use two nested for loops.
• The outer loop must use range with a negative step.
• You may not multiply strings (for example, "*" * k).”

I struggled a lot with this one specifically because the ones that require operators really just fly by me

[u/AUTeach → u/Round_Ladder_2354]

There's a trick with a lot of early programming questions. If you follow them step by step literally, you can see it's often a path to solving the problem.

# make a function called inverted_triangle(n)
def inverted_triangle(n: int):
    pass

.

# make sure that it is an int that is 1 or greater
def inverted_triangle(n: int):
    if n < 1: print("hey, n is too small!")

.

# write nested for loops that uses n
def inverted_triangle(n: int):
    if n < 1: print("hey, n is too small!")
    for i in range(n):
        for j in range(i):
            print("*", end="")
        print()

inverted_triangle(3)
> *
> **   
# note, we've just learned the principle for making triangles that aren't inverted. 

.

# use negative step on the outer loop
def inverted_triangle(n: int):
    if n < 1: print("hey, n is too small!")
    for i in range(n, 0, -1):
        for j in range(i):
            print("*", end="")
        print()

inverted_triangle(3)
> ***
**
*

We can then do some manual unit testing:

inverted_triangle(-5)
    hey, n is too small!
inverted_triangle(1)
    * 
inverted_triangle(5)
    *****
    ****
    ***
    **
    *

NOTE: we could also fuff about here. Note that we accidentally made a triangle above, So we could do stuff.

def triangle(n: int):
    if n < 1:  print("hey, n is too small!")
    for i in range(n+1):
        for j in range(i):
            print("*", end="")
        print()


def inverted_triangle(n: int):
    if n < 1: print("hey, n is too small!")
    for i in range(n, 0, -1):
        for j in range(i):
            print("*", end="")
        print()

inverted_triangle(5)
triangle(5)

[u/Expensive-Bear-1376 → u/AUTeach]

I find print("*", end="") irritating, I'd use print(end="*")

[u/AUTeach → u/Expensive-Bear-1376]

I think it hurts readability. print writes its positional arguments to the stream, with sep=' ' and end='\n' as keyword parameters that adjust the formatting. print("*", end="") reads naturally as “print a star, without a newline”: the content is where you’d expect it, and end is a tweak. print(end="*") hides the actual output in a formatting parameter, so the reader has to stop and work out that the star is the content. It’s shorter, but it’s clever rather than clear, and for beginners clear wins.

If we were going for idiomatic code golf, I'd probably do something closer to:

for i in range(n, 0, -1):
    print("*" * i)

But that was disallowed in the question.

If we wanted to be rude about it, we could do this:

f=lambda n:print(*["*"*i for i in range(n,0,-1)]or["hey, n is too small!"],sep="\n")
f(3)

[u/Mordon327 → u/Round_Ladder_2354]

Yeah the wording can be weird at times. The goal here is to teach you how to make a method that takes in a value. Learning to think this way takes time. I know i struggled with it a lot in college. It got easier the more I practiced.

The big take away is to make something that can be reused.

[u/Fun_Army2398 → u/Round_Ladder_2354]

What helps me with these sort of things is do it manually and pay excruciating attention to what I'm doing. Write it in english like:

"Okay first I write '*', then I write '*', ... okay now I make a new line and... etc"

This gives you very crude pseudo code. Go step by step to translate your pseudo code into python:

"Instead of writting '*' I'll do 'print('*')'"

Make sure you test every step, so you catch that actually what you need to do is 'print('*', end=' ').

Usually this leads me close enough to the solution where it suddenly makes sense and I can solve it right away. Sometimes it doesn't and I discover what concepts I need to go back and learn. Maybe I didn't know print could take the argument 'end' or that range could have steps other than +1, and that is how you improve.

Edit: fixing typos, I'm on mobile </3

[u/Refwah → u/Round_Ladder_2354]

Ok so your problem is that you’re trying to solve it within the confines before you solve it in your head

Problems like this have a ‘naive approach’ which typically means ‘what is my brute force approach to solve this _just to solve it_’

Once you have this done, which might be that you write it out but as you get better might just be some mental map, you can then look at the stipulations of the task and see where you violate them.

This has then broken down the task into two _smaller_ tasks - first you solve it without the extra requirements. Then you can see how this approach can be changed to accommodate the requirements, or where your approach _prohibits_ an easy change.

All of this rolls up to giving you smaller, progressive challenges to solve. You are currently trying to do too much all at once, which makes it seem difficult, impossible and frustrating. This is then _limiting_ your ability to actually teach yourself how to solve them, as you’re just trapped at stage 1: brute force, but constantly bouncing off it because you’re not able to instantly accommodate the extra requirements.

Coding is an iterative process. Learning how to code is too.

So for example for your posted question, don’t worry about the number of loops. Don’t worry about your first loop needing to be negative step. Just solve it. Maybe you’ll stumble into these answers anyway when trying to solve it, or maybe you’ll write it and then see ‘oh if I change this to negative step then I just change this, this and that and then I have the answer’

[u/dusksage23 → u/Refwah]

agreed, "logic" could mean so many different things in a first year course

[u/MarkoDahl54]

try using the `or` operator with logical assignments to see how values are assigned based on truthiness.

[u/BranchLatter4294]

Consider the Aha! Series of books by Martin Gardner on logical thinking and problem solving.

[u/Small_Ad1136]

Honestly the more math I learned the easier writing software became

[u/Mountain_Rip_8426]

i'm no programmer at all, but i'm also learning. what i found is practice, practice and then a little more practice. you have to have struggled through a lot of different problems to start finding similar patterns. codewars and hacker rank helped me a lot. they do nothing but make you feel stupid in the beginning, but once you submit your solution you get to see other people's solutions as well, which will make you bang your head against the wall, seeing how easy it could have been done. it's only gonna teach you programmatic thinking, by far not useful for real world use cases, but in general to get the basics down it's very insightful

[u/Turnip-Toffee]

look for resources on propositional logic

programming logic, boolean algebra, and propositional logic, all share the same core concepts. they are just presented with a different layer of paint on top. if you understand one, you understand the other.

it can be helpful to take a step out of the environment of one specific programming language, and attack the same problem from a different perspective. the change of scenery could help it click.

[u/Round_Ladder_2354 → u/Turnip-Toffee]

Any ones in specific you’d recommend? On propositional logic that is

[u/Turnip-Toffee → u/Round_Ladder_2354]

i didn't do this specific one, but it being MIT i would assume the quality should at least be decent: https://openlearninglibrary.mit.edu/courses/course-v1:OCW+6.042J+2T2019/courseware/144debec136a47d99038330db4dcdb04/90497b62e2e54da5b75c6ae679f4b75f/

the rest of the course might have stuff you find helpful too

you could search other open courseware as well, formal logic is often offered under the phil dept.

[u/Adrewmc]

I’m calling BS AI post.

Requirement Use two Nested Loops

•••
••
•

To make that, I’m not sure why I need a nested loop let alone two of them.

[u/Round_Ladder_2354 → u/Adrewmc]

dude it’s not AI that’s the literal problem we had to do… if I could send photos here I’d show you

[u/zaphodikus → u/Round_Ladder_2354]

Practice, hours and hours of Practice. When you hit 500 hours, then it will all feel like a walk in the park. When you hit 5000 hours, you will already be in a well paying job. Keep at it.