


 RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))                    1111....0000....44445555                     RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))
 rrrrrrrrddddttttoooooooollll                                                             rrrrrrrrddddttttoooooooollll
                                 2222000000002222----00002222----22226666



 NNNNAAAAMMMMEEEE
      rpntutorial - Reading RRDTtool RPN Expressions by Steve Rader

 DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
      This tutorial should help you get to grips with rrdtool RPN
      expressions as seen in CDEF arguments of rrdtool graph.

 RRRReeeeaaaaddddiiiinnnngggg CCCCoooommmmppppaaaarrrriiiissssoooonnnn OOOOppppeeeerrrraaaattttoooorrrrssss
      The LT, LE, GT, GE and EQ RPN logic operators are not as tricky as
      they appear.  These operators act on the two values on the stack
      preceding them (to the left).  Read these two values on the stack from
      left to right inserting the operator in the middle.  If the resulting
      statement is true, the replace the three values from the stack with
      "1".  If the statement if false, replace the three values with "0".

      For example think about "2,1,GT".  This RPN expression could be read
      as "is two greater than one?"  The answer to that question is "true".
      So the three values should be replaced with "1".  Thus the RPN
      expression 2,1,GT evaluates to 1.

      Now also consider "2,1,LE".  This RPN expression could be read as "is
      two less than or equal to one?".   The natural response is "no" and
      thus the RPN expression 2,1,LE evaluates to 0.

 RRRReeeeaaaaddddiiiinnnngggg tttthhhheeee IIIIFFFF OOOOppppeeeerrrraaaattttoooorrrr
      The IF RPN logic operator can be straightforward also.  The key to
      reading IF operators is to understand that the condition part of the
      traditional "if X than Y else Z" notation has *already* been
      evaluated.  So the IF operator acts on only one value on the stack:
      the third value to the left of the IF value.  The second value to the
      left of the IF corresponds to the true ("Y") branch.  And the first
      value to the left of the IF corresponds to the false ("Z") branch.
      Read the RPN expression "X,Y,Z,IF" from left to right like so: "if X
      then Y else Z".

      For example, consider "1,10,100,IF".  It looks bizzare to me.  But
      when I read "if 1 then 10 else 100" it's crystal clear: 1 is true so
      the answer is 10.  Note that only zero is false; all other values are
      true.  "2,20,200,IF" ("if 2 then 20 else 200") evaluates to 20.  And
      "0,1,2,IF" ("if 0 then 1 else 2) evaluates to 2.

      Notice that none of the above examples really simulate the whole "if X
      then Y else Z" statement.  This is because computer programmers read
      this statement as "if Some Condition then Y else Z".  So it's
      important to be able to read IF operators along with the LT, LE, GT,
      GE and EQ operators.

 SSSSoooommmmeeee EEEExxxxaaaammmmpppplllleeeessss
      While compound expressions can look overly complex, they can be
      considered elegantly simple.  To quickly comprehend RPN expressions,



                                    - 1 -        Formatted:  August 20, 2003






 RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))                    1111....0000....44445555                     RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))
 rrrrrrrrddddttttoooooooollll                                                             rrrrrrrrddddttttoooooooollll
                                 2222000000002222----00002222----22226666



      you must know the the algorithm for evaluating RPN expressions:
      iterate searches from the left to the right looking for an operator,
      when it's found, apply that operator by popping the operator and some
      number of values (and by definition, not operators) off the stack.

      For example, the stack "1,2,3,+,+" gets "2,3,+" evaluated (as "2+3")
      during the first iteration which is replaced by 5.  This results in
      the stack "1,5,+".  Finally, "1,5,+" is evaluated resulting in the
      answer 6.  For convenience sake, it's useful to write this set of
      operations as:

       1) 1,2,3,+,+    eval is 2,3,+ = 5    result is 1,5,+
       2) 1,5,+        eval is 1,5,+ = 6    result is 6
       3) 6

      Let's use that notation to conviently solve some complex RPN
      expressions with multiple logic operators:

       1) 20,10,GT,10,20,IF  eval is 20,10,GT = 1     result is 1,10,20,IF

      read the eval as pop "20 is greater than 10" so push 1

       2) 1,10,20,IF         eval is 1,10,20,IF = 10  result is 10

      read pop "if 1 then 10 else 20" so push 10.  Only 10 is left so 10 is
      the answer.

      Let's read a complex RPN expression that also has the traditional
      multiplication operator:

       1) 128,8,*,7000,GT,7000,128,8,*,IF  eval 128,8,*       result is 1024
       2) 1024,7000,GT,7000,128,8,*,IF     eval 1024,7000,GT  result is 0
       3) 0,128,8,*,IF                     eval 128,8,*       result is 1024
       4) 0,7000,1024,IF                                      result is 1024

      Now let's go back to the first example of multiple logic operators but
      replace the value 20 with the variable "input":

       1) input,10,GT,10,input,IF  eval is input,10,GT  result is A

      Read eval as "if input > 10 then true" and replace "input,10,GT" with
      "A:

       2) A,10,input,IF            eval is A,10,input,IF

      read "if A then 10 else input".  Now replace A it's verbose
      description and--voila!--you have a easily readable description of the
      expression:

       if input > 10 then 10 else input



                                    - 2 -        Formatted:  August 20, 2003






 RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))                    1111....0000....44445555                     RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))
 rrrrrrrrddddttttoooooooollll                                                             rrrrrrrrddddttttoooooooollll
                                 2222000000002222----00002222----22226666



      Lastly, let's to back the first most complex example and replace the
      value 128 with "input":

       1) input,8,*,7000,GT,7000,input,8,*,IF  eval input,8,*     result is A

      where A is "input * 8"

       2) A,7000,GT,7000,input,8,*,IF          eval is A,7000,GT  result is B

      where B is "if ((input * 8) > 7000) then true"

       3) B,7000,input,8,*,IF                  eval is input,8,*  result is C

      where C is "input * 8"

       4) B,7000,C,IF

      At last we have a readable decoding of the complex RPN expression with
      a variable:

       if ((input * 8) > 7000) then 7000 else (input * 8)

 EEEExxxxeeeerrrrcccciiiisssseeeessss
      Exercise 1:

      Compute "3,2,*,1,+ and "3,2,1,+,*" by hand.  Rewrite them in
      traditional notation.  Explain why they have different answers.

      Answer 1:

          3*2+1 = 7 and 3*(2+1) = 9.  These expressions have
          different answers because the altering of the plus and
          times operators alter the order of their evaluation.

      Exercise 2:

      One may be tempted to shorten the expression

       input,8,*,56000,GT,56000,input,*,8,IF

      by removing the redundant use of "input,8,*" like so:

       input,56000,GT,56000,input,IF,8,*

      Use tradition notation to show these expressions are not the same.
      Write an expression that's equivalent to the first expression but uses
      the LE and DIV operators.

      Answer 2:




                                    - 3 -        Formatted:  August 20, 2003






 RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))                    1111....0000....44445555                     RRRRPPPPNNNNTTTTUUUUTTTTOOOORRRRIIIIAAAALLLL((((1111))))
 rrrrrrrrddddttttoooooooollll                                                             rrrrrrrrddddttttoooooooollll
                                 2222000000002222----00002222----22226666



          if (input <= 56000/8 ) { input*8 } else { 56000 }
          input,56000,8,DIV,LT,input,8,*,56000,IF

      Exercise 3:

      Briefly explain why traditional mathematic notation requires the use
      of parentheses.  Explain why RPN notation does not require the use of
      parentheses.

      Answer 3:

          Traditional mathematic expressions are evaluated by
          doing multiplication and division first, then addition and
          subtraction.  Perentences are used to force the evaluation of
          addition before multiplication (etc).  RPN does not require
          parentheses because the ordering of objects on the stack
          can force the evaluation of addition before multiplication.

      Exercise 4:

      Explain why it is desirable for the RRDtool developers to implement
      RPN notation instead of traditional mathematical notation.

      Answer 4:

          The algorithm that implements traditional mathematical
          notation is more complex then algorithm used for RPN.
          So implementing RPN allowed Tobias Oetiker to write less
          code!  (The code is also less complex and therefore less
          likely to have bugs.)

 AAAAUUUUTTTTHHHHOOOORRRR
      steve rader <rader@wiscnet.net>




















                                    - 4 -        Formatted:  August 20, 2003



