[
https://issues.apache.org/jira/browse/QUARKS-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212341#comment-15212341
]
Dale LaBossiere commented on QUARKS-78:
---------------------------------------
PR #48 https://github.com/apache/incubator-quarks/pull/48
has been created for review.
I'm happy to address minor issues once/if it's decided to promote it to
quarks.analytics
> 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)
