boolean algebra

ganutenator · Jun 12, 2020

Have you checked it out.
I fell in love w/ it immediately.
I once had a boss that would make spaghetti code via huge function block diagram type drawings.
One time, I was able to reduce the entire 11 by 17 drawing down to one rung of ladder logic.
I thought that was F****ing hilarious.
It kind of falls apart (well, at least to me), when you have to add timers and oneshots to it.

James Mcquade · Jun 12, 2020

while you can do awesome things with various types of programming methods, it's still better to keep the logic in a state that maintenance can understand, find the issue, fix the problem, and keep the system running with minimal downtime. their happy, management is happy, their customer is happy, and you keep a customer happy and have more business in the future.
james

saultgeorge · Jun 12, 2020

James Mcquade said:
while you can do awesome things with various types of programming methods, it's still better to keep the logic in a state that maintenance can understand, find the issue, fix the problem, and keep the system running with minimal downtime. their happy, management is happy, their customer is happy, and you keep a customer happy and have more business in the future.
james

+1 on that.

ganutenator · Jun 12, 2020

I think reducing a full page of fbd logic down to one rung of ladder logic, did exactly that.

Peter Nachtwey · Jun 12, 2020

Way back when Terry Wood would go on and on about Karaugh maps. The trick is to get from one state to another without race conditions or unpredictable glitches. Since ladder doesn't scan infinitely fast like a FPGA or digital circuit made of gates there are fewer chances of having race conditions but I have seem them occur in PLC.

ganutenator · Jun 12, 2020

This was from when I worked in the oil fields in Bakersfield, CA.
Coming behind people and trying to figure out hacky spaghetti code was the worst.

ganutenator · Jun 12, 2020

But I agree, it is actually more difficult to make things simpler.
KISS principle.

kamenges · Jun 12, 2020

While James_Mcquade and I very seldom agree on programming complexity, boolean reduction is one area where we do agree. The act of reduction risks obscuring the intent of the logic. In addition, modifications need to be applied at the source equations prior to optimization, optimized and then coded. For the same reason I typically will fully represent equations in a plc program to avoid obscuring information. Granted, good documentation can help significantly in this case. The only place this thought process wouldn't apply would be if execution speed becomes and issue.

Keith

James Mcquade · Jun 12, 2020

to kamenges and all other members,

I do not wish to offend anyone with my comments and offer them based on my personal experiences. I apologize if I offend any one in my posts. while I am not the fastest or best programmer, I hope to use this site to keep learning and helping others.
james

kamenges · Jun 13, 2020

No offense ever taken, James. Opinion and perspective are important things to include in any discussion. As far as I am aware our "disagreements" have always been over opinion and perspective. So party on!!

Keith

alive15 · Jun 13, 2020

If you want to make a lot of money, you make it very complex. If you want to make it easy on people, you keep it simple. But remember the golden rule, what goes around, comes around! Maybe one day you will be stuck deciphering difficult code on a Friday evening, and wish the programmer made it simple for you too!!!

Steve Bailey · Jun 13, 2020

Maybe one day you will be stuck deciphering difficult code on a Friday evening, and wish the programmer made it simple for you too!!!

And it might even be code that you wrote several years ago! Many times I have asked myself, "what was I thinking"?

alive15 · Jun 13, 2020

Steve Bailey said:
And it might even be code that you wrote several years ago! Many times I have asked myself, "what was I thinking"?

Exactly Steve, I have done the same also! That feeling is a sure sign of growth in programming through experience over the years. Or perhaps we were in a bind, and needed to take a detour with our traditional programming practices to get the job done quickly. Us Programmers are always "In A Rush"!

drbitboy · Jun 13, 2020

Both verboseness and terseness can obfuscate; it's quite the tightrope act.

In the Linux kernel coding style guide, there is an interesting statement about comments, but which speaks volumes about the code itself:

Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it’s much better to write the code so that the working is obvious, and it’s a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW. ... [tell] people what it does, and possibly WHY it does it

One goal of that style guide is code maintenance on a collaborative project; that has some parallels with the integrator/customer relationship (or even the [me now]/[me six months from now] relationship

).

ganutenator · Jun 13, 2020

I may need to clarify.
I could be wrong, but I am getting the sense that many of you are thinking that I am adding complexity to the code.
I'm not talking about writing boolean algebra into the code. (don't even see how that is possible).
I'm talking about using boolean algebra on paper to help decipher code and then maybe writing it simpilar.

boolean algebra

ganutenator

Lifetime Supporting Member

James Mcquade

Member

saultgeorge

Lifetime Supporting Member

ganutenator

Lifetime Supporting Member

Peter Nachtwey

Member

ganutenator

Lifetime Supporting Member

ganutenator

Lifetime Supporting Member

kamenges

Member

James Mcquade

Member

kamenges

Member

alive15

Member

Steve Bailey

Lifetime Supporting Member + Moderator

alive15

Member

drbitboy

Lifetime Supporting Member

ganutenator

Lifetime Supporting Member

Similar Topics