Experimental Physics and
Industrial Control System

"Redman, Russell O." <[email protected]> · Thu, 27 Feb 2003 10:05:47 -0800

Dear Tim,

Ah yes, the operator priorities!  I had not stared sufficiently deeply into
the code to understand how they were used.  In practice, I would almost
always put parentheses around an expression using unfamiliar operators.
However, when every character counts, it is best to assign the priorities
correctly!  I would vote for priorities 5, 5 like multiplication.

I am intrigued by your exploration of variable argument lists.  If you can
make this work robustly, it is clearly the best approach.  Rock on!

Dr. Russell O. Redman
Tel: (250) 363-6917 | Fax: (250) 363-0045
<mailto:[email protected]>
National Research Council Canada | Conseil national de recherches Canada
5071 West Saanich Road           | 5071 West Saanich Road
Victoria, B. C. V9E 2E7          | Victoria, C.-B. V9E 2E7
Government of Canada             | Gouvernement du Canada

> -----Original Message-----
> From: Tim Mooney [mailto:[email protected]]
> Sent: Wednesday, 2003 February 26 8:46 PM
> To: Redman, Russell O.
> Cc: Tech-Talk (E-mail)
> Subject: Re: Long expressions using MAX and MIN in CALC fields
> 
> 
> "Redman, Russell O." wrote:
> > 
> > I would like to suggest a small enhancement for the calcRecord,
> > ...
> > My motivation for this change is that I would like to use a 
> SINGLE calcout
> > record to evaluate
> >   MIN(2,MAX(A,B,C,D,E,F,G,H,I))
> > ...
> > A much easier approach to implement is to treat MAX and MIN 
> as binary
> > operators.
> > ...
> > ...I suggest that "|<" and ">|"
> > might be suitable as binary MIN and MAX operators, respectively.
> > ...
> > In the postfix.c code, insert the two lines
> > 
> > {">|",  7, 8,      BINARY_OPERATOR, MAX}, /* maximum of 2 args */
> > {"|<",  7, 8,      BINARY_OPERATOR, MIN}, /* minimum of 2 args */
> >
> 
> Cool, but the parsing priorities (7,8) are too high.  "tan(a) >| b"
> actually
> gets evaluated as "tan(max(a,b))" -- REALLY not what you want!  Also,
> with
> (in-stack==7, incoming==8), the operators will associate from right to
> left.
> I think most folks would expect them to associate from left 
> to right, as
> "+"
> and "-" do.
> 
> I think a better set of priorities would be either (4,4) -- like
> addition --
> or (5,5) -- like multiplication.
> 
> Anyway, I got interested in playing around with a variable number of
> arguments,
> and found that calcPostfix() actually accepts "max(a,b,c)", 
> and produces
> postfix
> for it, though calcPerform() doesn't know what to do with the postfix
> expression,
> and returns an error because its value stack doesn't end up empty. 
> However,
> "max(a,b,min(c))" gets by both of these guys, because the total number
> of
> arguments matches the total number consumed by operators, and it
> produces the same
> result as "max(a,min(b,c))"!  Odd, but innocuous, I'm convinced: stack
> overflow
> is not a problem because the stack already has to be large enough for
> the worst-case
> expression, and an infix expression that would produce a 
> stack underflow
> in
> calcPerform would not have enough operands to pass 
> calcPostfix()'s final
> test.
> I don't think we're just lucky.  I think the person who wrote 
> this knew
> it was ok
> to test only for missing operands.
> 
> In all this messing around, I did get find a nice way to implement
> max(a,b,c,...),
> with two or more args.  sCalcPostfix shoves an end-of-operands symbol
> into the
> postfix expression when it sees MAX or MIN, and when sCalcPerform sees
> that, it shoves
> a NaN onto the value stack as a final operand not to be used. 
>  (Yeah, I
> know...What
> happens to a badly formed expression on a PPC?  It might be better to
> use a union
> instead of NaN.)  The code isn't ready for posting yet, and I haven't
> really tried
> hard to break it.
> 
> Tim Mooney
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System