"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
(instack==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 worstcase
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 endofoperands 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
<2003>
2004
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
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
