[jira] [Created] (QUARKS-78) Add Range analytic utility?

["Dale LaBossiere (JIRA)" <ji...@apache.org>]

Dale LaBossiere created QUARKS-78:
-------------------------------------

             Summary: Add Range analytic utility?
                 Key: QUARKS-78
                 URL: https://issues.apache.org/jira/browse/QUARKS-78
             Project: Quarks
          Issue Type: New Feature
          Components: Miscellaneous
            Reporter: Dale LaBossiere


A common sensor analytic is to filter for values being within, or outside of, a range. It's common for range values to be initialized from static properties files and/or dynamically set from external sources. 

e.g., a Range could be used for the band region of a deadband filter. 
```
Range<Integer> r = Range.closedOpen(3,7); // Integer range between 3-inclusive and 7-exclusive 
r = Range.valueOf("[3..7)", Integer.class); // same thing 
s = s.filter(tuple -> !r.contains(tuple)); // pass only tuples outside the range

// Range is generic type. 
// There are the full combination of two bound range ctors and 
// ctors for those with only a single bound, e.g., Range.atMost(7) // (-INF..7] ``` 

The Guava Range class offers a very convenient way for dealing with ranges. The Guava jar is significant in size. There are ways to mitigate that using ProGuard though it's not clear that approach would be appropriate for quarks/library use. See https://github.com/google/guava/wiki/UsingProGuardWithGuava 

The SensorAnalytics sample app added a very simple and lightweight Range implementation of a portion of the Guava Range API. Should that be incorporated into quarks.analytics.sensors to "make the simple simple"? 

[~djd] suggests that instead of using that Range impl, the actual Guava Range implementation be incorporated into Quarks. 

[~dlaboss] did some initial investigation. The Guava Range impl is dependent on several other Guava classes. Pulling on the thread will pull in a lot of things.  It's not obvious that quarks users will benefit from that "extra baggage". Perhaps starting with the simple, compatible, Range implementation in SensorAnalytics would be a good start. The sample's Range will be tidied up just in case. 

Moved from https://github.com/quarks-edge/quarks/issues/54



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)