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  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 
<== Date ==> <== Thread ==>

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

References:
Long expressions using MAX and MIN in CALC fields Redman, Russell O.

Navigate by Date:
Prev: RE: Long expressions using MAX and MIN in CALC fields Redman, Russell O.
Next: RE: Long expressions using MAX and MIN in CALC fields Redman, Russell O.
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 
Navigate by Thread:
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 
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 ·