Re: Index of highest value

["Lawrence T. Hoff" <hoff@bnl.gov>]

Andrew Johnson wrote:

> How about creating your own modified version of the SEL record with 
> slight modification to the code: In the calculation for SELECT_HIGH 
> (and probably for SELECT_LOW as well for symmetry) have it set 
> psel->seln=i as well as recording the highest value.  Then you can 
> read the SELN field to find the index you want.
>
> We probably ought to make this change in the Base version of the 
> selRecord as it seems like a common kind of issue, but I don't know 
> how many existing databases it might break so I'd welcome any feedback 
> positive or negative on the suggestion.


   Technically, that seems like an ideal solution to my particular 
application. It is simple
to implement, is logically consistent with the SEL record behavior, 
completely solves
my problem (e.g. I don't need a monitor on SELN), and is unlikely to be 
incompatible
with existing use.

   Sociology is another issue..... It seems unlikely to me that your 
suggestion would
break anything but the most contrived and non-mainstream application. 
However,
the larger the user base, the more likely contrived and non-mainstream 
applications
become!

   Once can certainly avoid breaking legacy application by introducing 
yet more
mode selections (e.g. "High Signal Index"), while leaving the behavior 
of existing
mode selections unchanged. However, that could lead to unecessary, and 
potentially
confusing "mode creep".

   I suppose big, bold warnings in EPICS release notes should be 
sufficient to
warn users of new record functionality that comes with new versions of 
EPICS,
especially if they come with guidance on how to work around new 
functionality
which "breaks" existing applications. I do wonder if anyone ever really 
reads
release notes before they commit to an upgrade, though........

   I could make my own record for my own application, but that seems a 
rather
heavy-handed approach, especially since I can use a group of CALC records
or a single SUBROUTINE record, and not incur the maintenance burden of
a new record (which has 99% functionality overlap with the SEL record).

   I look forward to watching the "social side" of how this issue plays 
out.
Meanwhile, I find that by pairing each of my "goodness" ao records with a
calc record, and using two SEL records, I can implement my application
in a understandable (IMHO) way, so the issue has become moot. If your
proposed functionality becomes available, all those CALC records and one
SEL record would become unecessary.

-- Larry