Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: Long expressions using MAX and MIN in CALC fields
From: "Redman, Russell O." <Russell.Redman@nrc-cnrc.gc.ca>
To: "'Tim Mooney'" <mooney@aps.anl.gov>
Cc: "Tech-Talk (E-mail)" <tech-talk@aps.anl.gov>
Date: 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:Russell.Redman@nrc-cnrc.gc.ca>
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:mooney@aps.anl.gov]
> 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
> 

Navigate by Date:
Prev: Re: Long expressions using MAX and MIN in CALC fields Tim Mooney
Next: Re: Long expressions using MAX and MIN in CALC fields Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: Long expressions using MAX and MIN in CALC fields Redman, Russell O.
Next: GPIB Driver for SCPI commands to an Ethernet device like Keithley 2701 Multimeter Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·