| Summary: | Function similar to Matlab's/Octave's colon operator | ||
|---|---|---|---|
| Product: | Eigen | Reporter: | Christoph Hertzberg <chtz> |
| Component: | Core - general | Assignee: | Nobody <eigen.nobody> |
| Status: | DECISIONNEEDED --- | ||
| Severity: | Feature Request | CC: | gael.guennebaud, jacob.benoit.1, megabyte |
| Priority: | Normal | ||
| Version: | 3.3 (current stable) | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 329 | ||
| Bug Blocks: | 814 | ||
What about introducing a more general Range object which could be specified in different ways, e.g.: Range<T,I> sizedRange(I size, T low, T high); Range<T,ptrdiff_t> steppedRange(T step, T low, T high); LinSpaced(sizedRange(4,0,15)) == LinSpaced(steppedRange(5,0,15)) This is just a rough description of what could be done, but the general idea here is that we have the same issue with block/segment (start/length, versus start/end, indexing even rows, etc.), and thus it would be nice to address them with the same mechanism. See bug 329. I see 3 different use cases: I size, T low, T high --> this is what LinSpaced does I size, T low, T step (this is what LinSpaced does internally) T low, T high, T step: calculate size=1+floor((high-low)/step) For the first two, size could also be specified at compile-time. And actually, if T is an integer, step may also be fixed at compile-time. We can't distinguish the above methods by overloading a constructor if we want to make T=I possible (which is required for Bug 329), so we probably need three classes for that (they can inherit from a common base class, of course). Regarding the first case, Bug 1004 is related. -- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/699. |
Sometimes, instead of using LinSpaced it would be more convenient to have an expression similar to Matlab's colon operator. E.g. 0:5:15 = {0, 5, 10, 15} (instead of LinSpaced(4,0,15)) Suggestion: DenseBase::Range(size, low, stepsize) and for fixed size types: Range(low, stepsize). However, if we default stepsize to 1, there would be an ambiguity between Range(size, low) and Range(low, stepsize). The return type could actually be shared with the current LinSpaced return type (at least for floating point types (cf. Bug 698). For dynamic sized ranges, instead of specifying the size an alternative syntax which requires an upper bound might also be possible. I'm also not sure, if Range is the best name for it.