Open hiiamboris opened 3 years ago
For a name /part
makes sense. No /width
as that's a required parameter already. Would then also need to decide if /part
and /index
work together. Since extract
is already a mezz, mocking this up should be easy.
USAGE:
EXTRACT series width
DESCRIPTION:
Extracts a value from a series at regular intervals.
EXTRACT is a function! value.
ARGUMENTS:
series [series!]
width [integer!] "Size of each entry (the skip)."
REFINEMENTS:
/index => Extract from an offset position.
pos [integer!] "The position."
/into => Provide an output series instead of creating a new one.
output [series!] "Output series."
width
here is internal name and can be changed at will.
While /part
has a totally different meaning: to limit the extraction region (for consistency with other series functions).
Or /size
if you don't like /width
;)
Ideally:
>> extract/width/part [1 2 3 4 5 6 7 8 9 10] 4 2 5
== [1 2 5]
For a mockup see #94
Yes, /width begins from /index.
I had a similar wish
The motivation is to have an easy way of splitting series into regular chunks (overlapping if needed).
@galenivanov at a glance, extraction of overlapping chunks seems to be a rare use case. What do you think?
@hiiamboris I agree that overlaping chunks are not used very often. A possible case is a filter-like code, that needs to know the neighbours of a value (usually done for large sets of data - needs a low-level implementation). My idea is that overlapping comes at no cost, when the part
argument is bigger than the skip
argument.
Or whatever name is better. See #94 for background, but this will be useful in any case.
Currently
extract
is limited to extraction of 1 item over period P, whereas it would be more powerful if we could extract N items over period P:Currently supported
/index
refinement OTOH is not really needed as it can be done withskip
(but perhaps a nice convenience).