Printable View
Hi,
if I try to write a big logic with many conditions then i am getting confused and not able to remember all the conditions. Can someone suggest me how to improve my logic? After some period of time i completely forget the logic. I am asking an OFF question, but someone if have any tips please suggest me, it will be of great help for me.
Thanks
If you're really just talking about remembering things:
If you're having trouble keeping all of that complicated logic in your head then...don't keep all of that complicated logic in your head. What do you normally do when you have trouble remembering things, or think you might forget something? Usually you write it down somewhere, make some notes, etc.
If you're talking about being able to come back to your code, and understand it:
- Work the problem out on paper first. This gives you a chance to work out any logic bugs and organize your thoughts/ideas/solution. Being organized before you start programming results in logic that is easier to understand and follow.
- Pick good variable and function names, that describe the purpose of a variable -- what it's value represents, or what it's used for. Calling variables num1 and num2 doesn't help me much, neither does calling a function calculate_values(). Variable names like student_age and student_score, and a function name like calculate_average_grade(), are much more helpful to figuring out what is going on.
- Break your code up into function. I put a "soft" limit of about one screen maximum (usually 50-80 lines) for a function. It is very rare that I ever need to exceed that, usually if I find myself above 40-50 lines for a function, there is a problem with my design. Also, functions should do one thing and do it well. Don't mix input/output with calculations. Keeping separate code separate helps you keep the complicated logic in small, containable, easy-to-understand chunks.
- Use comments. Every programming language has them. Don't make the mistake most newbies make, of commenting the obvious code, and leaving the difficult to understand code uncommented. I find good comments usually fall into 3 categories.
- First, documenting an interface: this is usually documenting a function. I like to include a one sentence summary along with a list of all parameters, any expectations of those parameters (e.g. list must not be NULL, length must be greater than 0), any changes to those parameters (num_students will be set to the new total number of students), and the return value (if any) along with what the meaning of that return value is. If the function is complex, I often have a more thorough description below the one sentence summary.
- Second, explaining complex code. I usually use this in complicated calculations ("use Riemann sum to estimate the area"). This clues the reader into what your code is actually doing.
- Third, explaining why your code does what it does. Sometimes in programming, we have to make decisions that result in code that seems counter-intuitive, or seems like a sub-optimal way of doing things, due to circumstances beyond our control. When you have to do something like this, it helps to explain why you chose this method, like "due to a race condition caused by the implementation of some_library_function(), I have to use this ugly hack to prevent the code from skipping elements with prime number indexes".
I agree; I think writing everything down on paper first is the best way of doing things.
¡puǝıɹɟ ɹnoʎ sı uoıʇɔɐɹʇsq∀Quote:
Originally Posted by testC
Andruil's answer is pretty on point unless you really mean Boolean logic and not something else.Quote:
Originally Posted by testC
To figure out a Boolean expression you just need to remember:
* Both parts of an AND expression needs to be true
* OR will evaluate each part of its expression until it finds something is true, or until the whole expression is false.
* NOT will flip the closest expression to the right (sometimes something complex in parentheses) from true to false, or from false to true.
There is no sense in figuring out complex Boolean statements, either. Visualizing de Morgan's laws will keep the operations optimal, and, to a point, keep things simpler. Apply the laws wherever you can.
If it ever gets too hard, just cheat with a "precedence table" until you can remember.
Any bit of complex logic deserves an English explanation too. A simpler expression might be devised if you or someone else comes across the problem expressed in a comment.
Ok, let's go back to basics.
Go to your fridge and grab two items. Looking in my fridge I have lots of things, it's very confusing. There are lots of different things though so I'm going to grab two different pieces of fruit and put them on my bench. I have a peach (very mouldy but don't worry about that) and I have a lemon. Grab two pieces of different kinds of fruit out of your fridge or from wherever and put them on your table. I'll continue using a peach and a lemon but use whatever you like. So, on my table I have:
1 lemon; and
1 peach
Don't worry about formal logic and all that rubbish for a while; we have a lemon and a peach and that's all. Looking at my recipe book I know that if I have 2 lemons I can make lemonade and that leads to a simple "natural language" statements: "If I have two lemons I can make lemonade". Let's pretend we like lemonade. How can we determine if we have the ingredients? Well, we've already said that we need two lemons, so make simple table using a piece of paper:
This translates directly to your statement/assertion/condition: IF fruit 1 = lemon AND fruit 2 = lemon THEN we can make lemonade!Code:Fruit 1 Fruit 2 Can make lemonade?
Lemon Lemon Yes!
Fill in the rest of the table yourself. It might look something like this:
What other statements can you make about this expanded table. You can, for example, say:Code:Fruit 1 Fruit 2 Can make lemonade?
Lemon Lemon Yes!
Peach Lemon No :(
Lemon Peach No :(
Peach Peach No :(
If Fruit 1 is a Peach and Fruit 2 is a Lemon the we cannot make lemonade.
Combined with the third item of the table you can clearly make the logical jump and state that if Fruit 1 is not the same as fruit 2 then no lemonade for you.
We've now made the following statements that are true:
a) If both fruits are a lemon then we can make lemonade
b) If the fruits are not the same then we cannot make lemonade
Expand these statements and ask questions.
If Fruit A AND Fruit B are both Lemons then... ?
If Fruit A OR Fruit B are a lemon then... ?
If Fruit A OR Fruit B are NOT a lemon then... ?
If Fruit A AND Fruit B are NOT a lemon then... ?
Answering these questions in natural language will provide you with insights regarding how combining logical and correct statements/expressions lead to a deeper understanding. At the end of the day you start with a statement/expression that is true and another that is not true. Just keep thinking about it in whatever your native tongue is. After a while you'll, perhaps, rediscover a set of laws known as De Morgan's laws. These really do just follow on from common sense and intuition. Take, for example, the statement "If both are not lemons we cannot make lemonade." This can, in natural language, be expressed in another way "If either fruit is not a lemon then we cannot make lemonade". Practice. Apply common sense and you really will get there.
Nice!Quote:
Originally Posted by Hodor
For some reason, I've found that a lot of people find this kind of straight thinking somewhat non-intuitive.
(...and end up trying to memorise code!)
I've noticed this, as well. While I don't really like coding in HDL (I don't get the same pleasure from it as I do C), I found that it really made boolean logic second-nature. Do enough simple K-maps, and a person can quickly convert a truth-table to a boolean expression mostly in their head.Quote:
For some reason, I've found that a lot of people find this kind of straight thinking somewhat non-intuitive.
O_oQuote:
Do enough simple K-maps, and a person can quickly convert a truth-table to a boolean expression mostly in their head.
Speak for yourself; after two variables I still get lost "in my head".
Soma
That's why I qualified it with "mostly" - for me, I still need to jot down some stuff on scrap paper as an extension of my thought process (my "RAM", if you'd like). But fairly simple* conversions of three or four values is sometimes achievable without the formalized process.Quote:
Speak for yourself; after two variables I still get lost "in my head".
(* I should have also qualified "fairly simple" truth-tables in my post - sorry for not being more clear)
O_oQuote:
I should have also qualified "fairly simple" truth-tables in my post - sorry for not being more clear
Why?
I got the idea; I was just commenting that I'm not good with "kmaps".
[Edit]
Although, I may return to this issue four years from now...
[/Edit]
Soma
I was just covering myself in case the "Pedant Necromancer" (:D) found that post in a few years and accused me of claiming I could do complex, multi-variable boolean simplification in my head.Quote:
Why?
I got the idea; I was just commenting that I'm not good with "kmaps".
[edit] Oh, I see you've already covered that!