All About Code Just another coder's food provider

Analytic
Application
DirectShowFilterGraph
DirectShowPluginControl
EndpointMapper
ForwardedEvents
HardwareEvents
Internet Explorer
Key Management Service
MF_MediaFoundationDeviceProxy
MediaFoundationDeviceProxy
MediaFoundationPerformance
MediaFoundationPipeline
MediaFoundationPlatform
Microsoft-IE/Diagnostic
Microsoft-IEDVTOOL/Diagnostic
Microsoft-IEFRAME/Diagnostic
Microsoft-IIS-Configuration/Administrative
Microsoft-IIS-Configuration/Analytic
Microsoft-IIS-Configuration/Debug
Microsoft-IIS-Configuration/Operational
Microsoft-PerfTrack-IEFRAME/Diagnostic
Microsoft-PerfTrack-MSHTML/Diagnostic
Microsoft-Windows-ADSI/Debug
Microsoft-Windows-API-Tracing/Operational
Microsoft-Windows-ATAPort/General
Microsoft-Windows-ATAPort/SATA-LPM
Microsoft-Windows-ActionQueue/Analytic
Microsoft-Windows-AltTab/Diagnostic
Microsoft-Windows-AppID/Operational
Microsoft-Windows-AppLocker/EXE and DLL
Microsoft-Windows-AppLocker/MSI and Script
Microsoft-Windows-Application Server-Applications/Admin
Microsoft-Windows-Application Server-Applications/Analytic
Microsoft-Windows-Application Server-Applications/Debug

wevtutil el

el | enum-logs          List log names.

wevtutil el | Foreach-Object { … commands go here … }

wevtutil cl “$_”

cl | clear-log          Clear a log.

wevtutil el | Foreach-Object {Write-Host "Clearing $_"; wevtutil cl "$_"}

The Truth table nightmare

Along my coding across many project I realised that implementing a truth table is always something either messy, either non easily scalable.

For those of you how wonder what the hell I’m speaking about, a truth table is just a table with one or multiple input condition and one or multiple output value.

For instance, here is the truth table for the && operator in c#:

A	B	A && B
True	True	True
True	False	False
False	True	False
False	False	False

Of course, this is an easy one, which you will code just by using the (A && B) bool.

But a truth table can be much more complex, using many many input operators. Across my code traveller adventure I saw two valid implementation of those kind of truth table.

The first one is the most easy to understand. The coder will just make one if then else at a time, putting them on into the other, like those Russian puppet.

I like to call this method of coding a Truth Table, the “Matroska If Then Else” method.
As coding the && c# operator table would be silly, let’s take another more complex Truth Table as example for our following samples:

Input Values			Output
TRUE	Orientation.X	Male	150
TRUE	Orientation.X	Female	321
TRUE	Orientation.Y	Male	587
TRUE	Orientation.Y	Female	235
FALSE	Orientation.X	Male	125
FALSE	Orientation.X	Female	369
FALSE	Orientation.Y	Male	147
FALSE	Orientation.Y	Female	152

As you can see, in this TT we don’t use only bool, but also some others type of data. But anyway, those kind of data can be easily converted to a double using a equality method.

In a “Matroska If Then Else” way, this would be the code:

However, with a few cleaning of the code, this sample could have been made easier, but I wanted to highlight the complexity of such a method.

It’s easy to write, fast to execute, but really, if you start having more then 5 input parameters, you’ll soon fall into a hell of a code, impossible to manage and update.

A second way to write those kind of Truth Table, when, and only when, the output value is only a bool (or a set of two value only that can be translated to a bool) is to use the Logical connective to condensate it into one single Boolean expression.

This is really a perfect way to make your application preferment, but be sure that if you exceed 3 or 4 input values again, none of the following coders who will come to update your code will be able to do it in 5 min.

Doing this, you are actually going a step deeper in the machine language, going away from the sacral abstraction of language that c# and modern programming language try to achieve.

So? Will you ask: what is your solution?
My point of view is easy: “If I have a truth table on paper, why can’t I write it in my application.”

To do so, I decided to have a dictionary of Key/value where my Key would be an object containing a set of input value, and my value would be the output value of my Truth Table:

I like to call this method the “True Truth Table” method

Using it require to create your own container object to represent the input set of value. In this case:

 

Then you are ready to eye-hand-copy-past your truth table from your flying paper to your code:

 

This way is much easier to manage, to update, even to understand as long as the coder doesn’t deep dive the details.

If a business man want to change the output result for “TRUE

 

Orientation.Y

 

Female” to 5000, this can be done in top 20 seconds.

Of course, this method may be slower to run then the two other as we create at least one object containing the different input value, but this could be optimized a bit by directly using the combined hash code of all input value.

Anyway, a dictionary is using an hash set / hash table / call it with the good name if you wish, but it’s kind of a fast stuff. So as long as you don’t call this method 5 million times a second, it shouldn’t affect your application.

What do you think about it? Any idea, improvement to propose? Feel free tor comment!

 

public override void Update(GameTime gameTime)
     {

         if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
         {
             //insert your code here
         }
     }