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

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

     [ https://issues.apache.org/jira/browse/QUARKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dale LaBossiere updated QUARKS-78:
----------------------------------
    Summary: Add Range analytic utility  (was: Add Range analytic utility?)

> Add Range analytic utility
> --------------------------
>
>                 Key: QUARKS-78
>                 URL: https://issues.apache.org/jira/browse/QUARKS-78
>             Project: Quarks
>          Issue Type: New Feature
>          Components: Analytics
>            Reporter: Dale LaBossiere
>            Assignee: Dale LaBossiere
>              Labels: newbie
>
> 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)