Like Tree6Likes
  • 2 Post By anduril462
  • 1 Post By Yarin
  • 1 Post By Hodor
  • 1 Post By phantomotap
  • 1 Post By Matticus

Remembering Logic

This is a discussion on Remembering Logic within the General Discussions forums, part of the Community Boards category; Hi, if I try to write a big logic with many conditions then i am getting confused and not able ...

  1. #1
    Registered User
    Join Date
    Feb 2014
    Posts
    1

    Remembering Logic

    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

  2. #2
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,498
    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".

  3. #3
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,084
    I agree; I think writing everything down on paper first is the best way of doing things.

  4. #4
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,628
    Quote Originally Posted by testC View Post
    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
    ¡puǝıɹɟ ɹnoʎ sı uoıʇɔɐɹʇsq∀
    manasij7479 likes this.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  5. #5
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,707
    Quote Originally Posted by testC View Post
    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
    Andruil's answer is pretty on point unless you really mean Boolean logic and not something else.

    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.

  6. #6
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    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:

    Code:
    Fruit 1            Fruit 2            Can make lemonade?
    Lemon            Lemon            Yes!
    This translates directly to your statement/assertion/condition: IF fruit 1 = lemon AND fruit 2 = lemon THEN we can make lemonade!

    Fill in the rest of the table yourself. It might look something like this:

    Code:
    Fruit 1          Fruit 2          Can make lemonade?
    Lemon            Lemon            Yes!
    Peach            Lemon            No :(
    Lemon            Peach            No :(
    Peach            Peach            No :(
    What other statements can you make about this expanded table. You can, for example, say:

    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.
    manasij7479 likes this.

  7. #7
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by Hodor View Post
    Ok, let's go back to basics.
    Nice!
    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!)
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  8. #8
    Registered User
    Join Date
    Jun 2011
    Posts
    2,374
    For some reason, I've found that a lot of people find this kind of straight thinking somewhat non-intuitive.
    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.

  9. #9
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,261
    Do enough simple K-maps, and a person can quickly convert a truth-table to a boolean expression mostly in their head.
    O_o

    Speak for yourself; after two variables I still get lost "in my head".

    Soma
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  10. #10
    Registered User
    Join Date
    Jun 2011
    Posts
    2,374
    Speak for yourself; after two variables I still get lost "in my head".
    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.

    (* I should have also qualified "fairly simple" truth-tables in my post - sorry for not being more clear)

  11. #11
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,261
    I should have also qualified "fairly simple" truth-tables in my post - sorry for not being more clear
    O_o

    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
    anduril462 likes this.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  12. #12
    Registered User
    Join Date
    Jun 2011
    Posts
    2,374
    Why?

    I got the idea; I was just commenting that I'm not good with "kmaps".
    I was just covering myself in case the "Pedant Necromancer" () found that post in a few years and accused me of claiming I could do complex, multi-variable boolean simplification in my head.

    [edit] Oh, I see you've already covered that!
    anduril462 likes this.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. remembering operator precedence
    By Satya in forum C Programming
    Replies: 5
    Last Post: 02-21-2012, 09:51 PM
  2. Arrays - used for remembering integers
    By kaopei in forum C Programming
    Replies: 2
    Last Post: 11-17-2010, 12:43 PM
  3. Need help with remembering numbers
    By SebastionV3 in forum C++ Programming
    Replies: 14
    Last Post: 05-08-2006, 02:39 AM
  4. Google remembering my keywords
    By m712 in forum Tech Board
    Replies: 4
    Last Post: 07-26-2003, 11:48 AM
  5. need help remembering
    By Treu in forum C++ Programming
    Replies: 1
    Last Post: 02-22-2003, 08:41 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21