edgent-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale LaBossiere (JIRA)" <j...@apache.org>
Subject [jira] [Created] (QUARKS-107) Add sample use of new Range class in recipe3 - detect value out of range?
Date Fri, 01 Apr 2016 20:17:25 GMT
Dale LaBossiere created QUARKS-107:

             Summary: Add sample use of new Range class in recipe3 - detect value out of range?
                 Key: QUARKS-107
                 URL: https://issues.apache.org/jira/browse/QUARKS-107
             Project: Quarks
          Issue Type: Improvement
            Reporter: Dale LaBossiere

Add sample use of new Range class in recipe3 - detect value out of range?

Either or both of the recipe's existing samples could be use Range, or one of them could be
cloned to use it.

TStream<Double> simpleFiltered = temp.filter(tuple ->
            tuple < TEMP_LOW || tuple > TEMP_HIGH);
// could be
TStream<Double> simpleFiltered = temp.filter(Ranges.open(TEMP_LOW, TEMP_HIGH);

TStream<Double> deadbandFiltered = Filters.deadband(temp,
            identity(), tuple -> tuple >= TEMP_LOW && tuple <= TEMP_HIGH);
// could instead be
TStream<Double> deadbandFiltered = Filters.deadband(temp,
            identity(), Ranges.closed(TEMP_LOW, TEMP_HIGH));

Use of a Range simplifies the code a bit.  I can also avoid mistakes if one's code "duplicates"
the expressions for a particular range in multiple places.  

Using Range can be more compelling for the simplicity with which a range may be expressed
and created from a config file for an app.  e.g. imagine how one would express the range in
a Properties config file.  A range property value in a Properties file would simply be:
# my sensor filter range
and the app code to create the Range would simply be:
Range<Double> myFilterRange = Ranges.valueOfDouble(props.getProperty("myFilterRange"));

Another compelling case is making a filter range dynamically changeable, for example as a
result of some received IoT "device command".  The range could be declared like:
AtomicReference<Range<Double>> myFilterRange = new AtomicReference<>(
    Ranges.valueOfDouble(props.getProperty("myFilterRange"));  // initial range value

// code in the device's set-filter-range cmd handler is ultimately:
//   myFilterRange.set(Ranges.valueOfDouble(the-new-range-string-from-the-cmd));  // sets
a new Range object

// Using the changeable filter range is simply:
TStream<Double> simpleFiltered = temp.filter(myFilterRange.get());

Dynamic filter Predicates is probably a good recipe unto itself :-)

This message was sent by Atlassian JIRA

View raw message