Re: hardcoded median function in phosphor-virtual-sensor

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Tue, Jan 05, 2021 at 09:38:12AM -0800, Ed Tanous wrote:
> On Tue, Jan 5, 2021 at 7:59 AM Matt Spinler <mspinler@linux.ibm.com> wrote:
> >
> > Also, we need a slightly tweaked median of our 3 ambient temp sensors:
> > 1) throw out values outside of minInput/maxInput
> > 2) if there is an even number, because we threw out one, choose the
> > higher value, and
> >      don't do the average of the 2  that I believe an actual median
> > would use.
> > 3) if we threw out all 3 (very unlikely), use NaN as the sensor value.
> >
> 
> These kinds of corner cases are exactly why IMO C++ is easier in the
> long run.  Those 3 conditions are trivial to add to a C++ based
> daemon, but would require a lot of complex expertk code to define if
> the corner cases were found later.  In C++ they just end up as an
> extra branch.

I would agree.  If these are the kinds of problems that we end up
solving with PVS, exprtk is not appropriate.  The initial problem
attempting to be solved was "I have a small set of sensors that I need
to do some relatively simple math on".  The moment your "virtual sensor"
has an if-condition, exprtk is probably not the right screwdriver to
hammer with.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]