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] [Resolved] (QUARKS-78) Add Range analytic utility
Date Fri, 01 Apr 2016 19:38:25 GMT

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

Dale LaBossiere resolved QUARKS-78.
    Resolution: Fixed

> 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

View raw message