Experimental Physics and Industrial Control System
Actually, Andrew, changing the parser to use infix notation was trivial, as
my original message indicated. The only change needed is that two-line
addition to the table of operators. I have tested this and verified that it
works. If there is a pseudo-standard (g++) that uses ">?" and "<?" for the
infix MAX and MIN operators, then I will cheerfully switch to that.
I think it would be hard to modify the parser to recognise variable numbers
of arguments. I much prefer this notation, but I really do not see an easy
way to do it.
I am using genSubRecords in other places, but they have overhead of their
own and are not as easily understood or debugged as a calcoutRecord. The
calcoutRecord does EXACTLY what I want, except that the CALC field was too
small for the expression in its original form.
Thanks for the thoughts!
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: Andrew Johnson [mailto:[email protected]]
> Sent: Wednesday, 2003 February 26 4:48 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,
> > calcoutRecord and waitRecord code that uses the postfix
> routine. This
> > enhancement will allow the MAX and MIN operators to be used
> on many more
> > input fields than is currently possible due to the limited number of
> > characters permitted in the CALC fields of these records.
>
> I like the idea that MAX and MIN should be able to take
> variable numbers
> of arguments, using this syntax:
>
> > MAX(A,B,C,D,E,F,G,H,I)
>
> However I'm not sure how easy this would be to add to the parser.
>
> > I know I can do the calculation with a select record
> > and a calcout, but these records are used in a time
> sensitive part of my
> > database and the calculation is nested quite deeply. If at
> all possible, I
> > would like to complete the operation using a single calcout record.
>
> I would have thought that a subroutine record would be significantly
> faster than using a calc for this - admitedly it's not going
> to be quite
> as flexible at runtime, but a lot less work in the short term than
> changing the calculation engine and parser.
>
> If you need the output capability of calcout, you might want
> to look at
> Andy Foster's genSub record which is an enhanced subroutine
> record that
> provides output links.
>
> > Unfortunately, most of the obvious punctuation characters have
> > already been used for other operations, but I suggest that
> "|<" and ">|"
> > might be suitable as binary MIN and MAX operators, respectively.
>
> The GNU C++ compiler has a built-in extension for MIN and MAX
> that uses <?
> and >? respectively as the binary operators. Although I'd
> prefer that we
> stick as close as possiblt to the standard C operators and function
> syntax, if a variable-length MIN() and MAX() can't easily be
> developed
> it's probably better to regard g++ as a sort of standard and
> re-use their
> operators.
>
> - Andrew
> --
> Tongue-twister: Say "Peggy Babcock" 10 times without stumbling...
>
- Navigate by Date:
- Prev:
Re: Long expressions using MAX and MIN in CALC fields Andrew Johnson
- 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
2020
2021
2022
2023
2024
- 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 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
2020
2021
2022
2023
2024