Terry Blackburn on the Web!

Home! | Earthquake Central | Old Website
DeskCam | Who am I? | Why is this site here? | Wild Ideas!
Musical Experiences | The Temperament Project | Catalog (stuff I've written)
Standard Photography | Photographic Theory | 3D Photography | Stereographic Theory
Iceland | Road Trip 2009 | Scotland & Ireland | Australia & New Zealand | MORE...
Current Local Conditions | Satellite View | Local Forecast | National Weather Service (NOAA)
Pond | Carnivorous Plant Bog | Heather Garden | The Cardiocrinum Project

Basic Concepts and Theory...

The purpose of this document is to describe algorithms presented in the form of mathematical formulae that can perform basic logic comparison and redirection.  The examples included below are not intended to convey an academic representation of the concepts being described here.  They are presented in a manner intended for 'practical' application rather than theoretical analysis.  The algorithms described were developed using strict empirical analysis rather than through the application of number theory.  This concept was developed to overcome limitations in computer based database analysis tools that do not support traditional If / Then logic control.  Most of these tools do allow the insertion of computed values into their processing.

The key to encoding binary logic into equations is based on concepts of simple division and multiplication.  For example, where x <> 0…

Let's review another mathematical concept – division of zero:
Oooh, that nasty division by zero.  Traditionally we are taught that division by zero is undefined.  Computers get really frustrated with any attempt to divide by zero. But, what about division of zero by zero?  The trend as demonstrated above is obviously toward zero.  Now it becomes necessary to call upon the calculus for assistance.   I believe division of zero by zero might be more likely expressed simply as:
Division by zero remains undefined for all non-zero numerators.

Practical Application
The scenario - Let's say you are a patient in my hospital.  You came in this morning with acute and life threatening symptoms.  After a series of lab tests and x-rays, your condition is stabilized and, after a period of observation, you are sent home.  The services you were provided were of inpatient intensity, you occupied a hospital bed, and commanded the attention of a full compliment of hospital staff.  Your stay, according to government regulations, is counted as one patient day.

Now, suppose you had stayed over night.  Your condition eased somewhat, but the specialist referred to your case by your primary care physician decides you need to stay over for further observation.  In the morning you are fine, and you are sent home.  This stay, according to business practice (driven again by governmental regulations) is also classed as a one day stay.

Next, hospital administration is doing a business analysis and asks you to calculate the number of patient days utilized during the past week.  I could write a program with a simple procedure to handle this specific calculation –

Procedure calc_days(admit_date,discharge_date,days)

  define admit_date as date
  define discharge_date as date
  define days as integer
  define total_days (global) as integer

  days = discharge_date – admit_date
  if days = 0 then days = 1
  total_days = total_days + days

end procedure

Unfortunately, programs are expensive to write, debug and maintain.  This simple data extraction could be created using a standard database tool except for the If / Then logic.  It just so happens we can implement the If / Then logic mathematically using the concepts of simple math we have learned above.  We can insert the following formula into our report writer and accomplish the same thing.

Days = 1 + ((disch_date – admit_date) - ((disch_date – admit_date) / ((disch_date – admit_date) + .0000000001))

So, what's this .0000000001 stuff?  We already know our computer will choke if we try to divide by zero.  So, what's really close to zero, but not quite?     For most practical purposes we can agree that x approaches zero at .00000000001.  Perhaps we could state the rule above as "Division of zero by zero equals zero for very large values of zero."  (Note: Mathematicians, smile, it's a joke!) The value .00000000001 performs as a safety valve to prevent chaos resulting from the actual division by zero.  The (x / x) portion of the formula creates a sort of logic gate that I call a control value.  Reducing our control value to a 1 or zero by dividing it by itself and then re-introducing it into the equation as a multiplier controls the output of the formula based on supplied data values.

Let's break it down.  The basic form is days = 1 + (x – (x / x)) where x is the positive difference between admit and discharge date.  The key is in x / x.  If x > 0 then  x / x = 1.  If x = 0 then x / x = 0 as defined in the introduction.  Now,  look what happens in the basic formula when x = 0 or 1!  Run a few quick calculations in your head.

Fiscal Quarter Calculation --

the problem - My hospital's fiscal year begins October 1st.  First quarter is the months of Oct. - Dec.  Second quarter is Jan - Mar etc.

Step one - Calculate calendar quarter - Calculating the quarter based on a calendar month has its own challenges, though these challenges are not directly logic related.

 3 months per quarter
 Calculate using integer values, no rounding
 month = 1 = m (integer between 1 and 12)
 integer(m / 3) + 1 = 1   OK

 m = 2
 integer(m / 3) + 1 = 1 FINE

 m = 3
integer (m / 3) + 1 = 2  OOPS!

The third month was supposed to fall into the first quarter.  So, we'll slide the month down a half notch, still using integer values with no rounding...
 m = 3
 integer((m - .5) / 3) + 1 = 1
And so forth...

Step two - rotate! (a rotating FABLE)  Fourth quarter needs to become first quarter, first becomes second, etc...  This gets really hairy, but here's what happens.  The 'trick' value is 4.  That's the value that needs special treatment, the 'control value.'  The equation needs to be set up in such a way that the input variable (the value of the calendar quarter) is reduced to a one or a zero (binary values) based on whether or not the quarter is equal to 4.

In this example, it just so happens that the numbers 6 and 10 play an important role in the process.  10 is a nice round number for multiplication and division, and adding 6 to our control value of 4 yields a 10.  The basic computation rule is no rounding of integer values or calculations.  Variables are assigned as follows:

calendar quarter = q
fiscal quarter = f

The equation looks like this:

f = (((((q + 6) / 10) - integer((q + 6) / 10)) * 10 - (((((q + 6) / 10) - integer((q + 6) / 10)) * 10/(((((q + 6) / 10) - integer((q + 6) / 10)) * 10-.00000001)) * 6) + 1

No, I don't really expect anyone to successfully navigate that mess.  I'm not even sure the parenthesis balance.  And furthermore, that's not how I initially devised it anyway.  That's just the logical extension of the following series of smaller formulas that more clearly illustrate the problem and its solution.  There's probably a really cool algebraic reduction of the 'formula' above.  If you work it out, send it to me!  I worked out the solution rather empirically using the steps below.

 q = calendar_quarter (integer between 1 and 4)
  1. fq = q + 6
  2. fq1 = integer(fq / 10)
  3. fq2 = fq / 10 (precision 9.9)
  4. fq3 = (fq2 - fq1) * 10
  5. fiscal_qtr = fq3 - (( fq3 / ( fq3 - .0000001)) * 6) + 1

 so: if q = 3 then

  1. fq = 9
  2. fq1 = 9 / 10 =  .9 = 0
  3. fq2 = 9 / 10 = 0.9
  4. fq3 = (.9 - 0) * 10 = 9
  5. fiscal_qtr = 9 - ((9 / ( 9 - .000000000001)) * 6) + 1 = 4

 if q = 4 then

  1. fq = 10
  2. fq1 = 10 / 10 = 1
  3. fq2 = 10 / 10 = 1
  4. fq3 = (1 - 1) * 10 = 0
  5. fiscal_qtr = 0 - ((0 / (0 - .00000001)) * 6) + 1 = 1
Whew!  You can try the values 1 and 2 on your own.  Step one moves our 'problem' value of 4 to 10.  Steps 2-4 set up the calculation to determine whether or not the initial value was 4.  In this case, zero asserts a true condition and one is false.  The actual binary calculation (x / x) occurs in step 5 where the decision is made whether to subtract the original six from our computed value before incrementing it to the actual new fiscal quarter value.  I believe numeric values other than six and ten could be used, however the process isn't as clear due to increased decimal precision requirements.

How about Absolute Value?

Here's the formula (FABLE) for calculating absolute value.  It's the same sort of thing - create a 1 or 0 depending on whether positive or negative, using truncated division.

  1.  w = (x / x + .000000001) gives us a 1 if x is negative, or a 0 if it's positive.
  2. Now, to convert that to a factor that you can use to multiply by to change the sign do this:  y = (w * -2) + 1.  if w = 1, denoting a negative number, 
    1 * -2 = -2 + 1 = -1, or if w = 0, then 0 * -2 = 0 + 1 = 1
  3. then z = y * x.

Or, in one big lump...  |x| = ((x / x +.0000001) * -2 + 1) * x

Are you ready for another one?

Column Tabulation

the problem - categorize data based on arbitrary criteria.  For example, tabulate length of stay into columnar categories i.e.

Patient name < 2 weeks 2wk to1month 1mo to 3mo 3mo to 6mo > 6mo
Patient a     1    
Patient b   1      
Patient c       1  
Patient d 1        
Patient e   1      
Patient f         1
Patient g     1    
Patient h   1      
Patient i       1  
TOTALS: 1 3 2 2 1


The value of the variable losdays (in formulae below) is calculated using the length of stay formula described above.  The length of stay is converted to a one or a zero depending on whether it is greater or less than the criteria specified for the column being calculated.  Greater than ( > ) converts to a 1.  Less than or equal to ( <= ) converts to a 0.  Remember – remainders get truncated.

Column 2 preliminary calculations – 2 weeks (14 days) or more?
 los2wka = integer(losdays / 14)
 los2wkb = integer(los2wka / (los2wka - .000000001))

Column 3 preliminary calculations – greater or less than 30 days?
 los1moa = integer(losdays / 30)
 los1mob = integer(los1moa / (los1moa - .0000000001))

Column 4 prelims – How about 90 days?
 los3moa = integer(losdays / 90)
 los3mob = integer(los3moa / (los3moa - .0000000001))

Column 5 prelims – 6 months…
 los6moa = integer(losdays / 180)
 los6mob = integer(los6moa / (los6moa - .000000001))

These are preliminary calculations.  All we're testing here is whether the supplied value is greater or less than the divisor in each formula set.  Example:  If the length of stay is 45 days, column two computes to a value of 1, column three computes to a value of 1, and the rest compute to zero.  In this case, 1 asserts true, 0 is false.  So, we've been able to assert that 45 is greater than 14, greater than 30, but less than 90 or 180.  You notice we left out column 1.  Column 1 is always true since by definition the patient will have been in house at least one day.

Now, subtract the binary value computed for the next column from the current column to see which column gets flagged.  These are the values we print in the columns on the report.

Column 1 final  - 0 to 2 weeks
 1 - los2wkb

Column 2 final - 2 to 4 weeks
 los2wkb - los1mob

Column 3 final - 1 to 3 months
 los1mob - los3mob

Column 4 final - 3 to 6 months
 los3mob - los6mob

And in column 5, we simply publish the value of

Continuing our example, we only want to mark a one in the column representing the range of values specified in the column header, and not every column up to that value.  So in computing the value for column 1, we look to see what value has been computed for column 2.  Since we're dealing with binary values, we can simply subtract the value of the next column from the current column.  Column 1 will then be calculated as (1 - column2) = (1 - 1) = 0.  Column 2 = (column2 - column3) = (1 - 1) = 0.  Column 3 = (column3 - column4) = (1 - 0) = 1.  Column 4 = (column4 - column5) = (0 - 0) = 0 and so forth.  So, only column 3, 30 to 90 days is marked with a 1.  Cool, huh!

The real bonus? Totals for each category can be produced using data summary functions.  Simply add up the 1's in each column and you have the total number of patients that met the criteria for each column.

Author's note:  There are lots more fun and interesting applications of this concept.  However - I must put on my system services administrator's hat here for a moment.  Programs and database queries created using this technique can be extremely difficult to maintain.  It may make perfect sense today, but six months or a year from now, you're not going to have a clue how that incredible jumble of numbers was supposed to produce any meaningful output.  Like I said, it's  fun and interesting.  Just don't use it in production unless the environment in which it is implemented accommodates voluminous commentary.  You've been warned...

These formulae were devised for use in a specific report writer tool -  IBM's QUERY/400 product, available on the AS/400 platform.  They are not intended to convey an academic representation of the concepts being described here.  They are presented in a manner intended for 'practical' application rather than theoretical analysis.

While I am not aware of any other applications or implementations of formula based algorithms utilizing binary logic encoding, I'm sure they exist.  I do, however, lay claim to having originated the term FORMULA-BASED ALGORITHMS WITH BINARY LOGIC ENCODING and the acronym FABLE to describe the concept.  That's my 20 seconds of fame!

Terry Blackburn
System Services Coordinator
Tuality Healthcare
©Terry Blackburn - 1998, 2000
About Me | Site Map | Privacy Policy | Contact Me | © 2004 Terry Blackburn