Jump to content

Ben Johnson

Seeq Developers
  • Content Count

    23
  • Joined

  • Last visited

  • Days Won

    6
  • Points

    2 [ Donate ]

Ben Johnson last won the day on July 9

Ben Johnson had the most liked content!

Community Reputation

7 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There's one small shortcut hidden at the bottom of the tool. If you check that before you finish the first column import, it will return you to the tool with many of the same values preserved. At least you don't need to re-upload the file 9 more times; you just pick the other data column, customize the unit and repeat.
  2. The subtlety in the last option of filtering by sample values rather than capsule properties is that the maximum interpolation of the signal may span over the removed samples, resulting in extra time for the adjacent states.
  3. Solution 3 Pure Seeq Formula The desired condition can be expressed in one step with Seeq Formula: periods(5 months, 1 year, '2015-05-01') That function allows you to mix the durations of the capsules with a different period. The 3rd parameter is an example origin for the capsule. In this case you could pick any year, as long as it starts on May 1 and the engine will create capsules using various increments of the period. (There's also a 4th parameter that can be used to fine tune the timezone of the midnight origin)
  4. The worksheet timezone changes the display of the timestamps, but it doesn't change the actual timestamps of the capsules. By default, all the periodic conditions are generated according to the server timezone. This can be overridden in in the advanced section of the tool as shown below. Selecting the correct timezone is important because it affects edge cases like daylight savings. Selecting a timezone that honors DST will produce the 25 or 23h capsule on the proper adjustment day.
  5. Predicting into the future is a great use of now(), and it's uncertainty is a key part of keeping the predicted data from polluting the cache. I'm sure you're working toward your own use case, but here's a different approach that's a bit more concise (and uses some newer functions). I'm sure we agree that yesterday's temperature has no prediction value for future, but that's just the demo data. It seems you're just looking for a golden batch to repeat with some adjustment into the future // extract a single good day to repeat, then repeat it every day $repeatShape = referenceTable(5min) .addRow($temp, capsule("2019-05-15")) .repeatOver(days(), ReferenceTableStat.Average) // this is 5F/day rise since now $slopeLine = timeSince(now(), 1d).setUnits('F') * 5 // stitch known with future $temp.forecastSplice($repeatShape + $slopeLine )
  6. Yes. It may seem odd to call now() "uncertain" - don't we have accurate clocks? It really means that the value will change, and any computation using that value is likely to get get different results in the future so it shouldn't be cached. The reference series feature is really designed to create static profiles - the performance impact of having to recompute the profile every time that it is used was considered too great. So I don't think there's a workaround. Perhaps you could describe your use case where a dynamic profile has significant value over the static profile? Are the profiles expected to change significantly over time such that recent behavior is more relevant than a training window(s) that was identified as the "golden batch"? If there are interesting use cases, perhaps it's worth filing a feature request as a result.
  7. This is a creative solution, but I wouldn't depend on it. It's exposed a bug in the delay() function regarding uncertainty. The offset that is being passed to delay() is "uncertain". That means it's possible the value could change. But delay() is not reflecting the uncertainty of the offset in its output properly (the whole signal should be uncertain), which makes it possible to use the delayed signal in the reference profile. You'll see the negative effects of this after a few days - the portion of the signal that was cached using an older training window won't get updated to reflect the more recent training window.
  8. ConvertUnits requires a compatible units of its input and will do the scaling. Some examples 5m.convertUnits('cm') = 500cm. 5m.setUnits('cm') = 5cm 5m.setUnits('g') = 5g 5m.convertUnits('g') is an error I'm a bit surprised by the failure in your 2nd case. setUnits should never fail (almost - there are edge cases in converting string and numeric). I imagine the issue is that the underlying signals have incompatible units for the math prior to the setUnits. If you have the formulas you tried, we can see if there are precedence issues vs actual bugs.
  9. The alternative to setUnits is convertUnits. The former just adds overrides the current value with the new unit, the latter applies the math needed to the existing values. For your case you should probably use ($a/($b+$c)).convertUnits('%')
  10. You can create more specialized periodic conditions using the "periods()" function in the formula tool. For example "periods(1min)" will give you one capsule every minute. That condition can then be used in the signal from condition tool. The periods function can also create overlapping or gapped capsules. For example, if you wanted to compare your actual signal against 5 minutes of data but do it every minute, you'd use "periods(5min, 1min)". (Then you'd probably want to align your signal from condition on the middle of the capsules)
  11. In versions up through R21.0.40, you can use the the filter function, such as $condition.filter($capsule -> $capsule.duration() > 1min) Where the expression inside the filter is evaluated for which capsules to keep. This will be even easier in the upcoming release of R21.0.41 when you can do $condition.removeShorterThan(1min)
  12. The hover cursors are always subject to the resolution of the screen. You can see the precise start date of that capsule in the capsule detail pane in the lower right. It looks like your reference signal might be off an hour or two, probably due to timezone adjustments. You can adjust the capsule or the days() formula with a timezone parameter in order to get it to repeat over the right day boundaries.
  13. It's possible to do it with a reference profile. Reference profiles are usually for aggregating multiple training periods, but if you take the average of just one period, it's equivalent to capturing the slice of the signal you want. Here's a formula that gets the gist of it: referenceTable(5min) .addRow($inputSignal, capsule('Feb 13 2019')) .repeatOver(days(), ReferenceTableStat.Average)
  14. The min/max functions have been added to the latest general release, R21.0.40.05
  15. You've found a bug! It's a two-fold issue The histogram is localizing the "day of week" labels using your browser's settings (The rest of the app is in English, but I infer your browser is set to prefer German) That localization code is treating the "start of the week" differently. Much of the world starts their week on Monday, others start it on Sunday, so there's an off-by-one error in looking up the proper label. I've filed CRAB-14766 so that we can track this. You've identified a creative workaround that sidesteps the bug. If your analysis can be done in English (US), changing your browser settings would also resolve it. Thanks for the question!
×
×
  • Create New...