On Tuesday, 9 May 2017 at 17:35:18 UTC, 9il wrote:
Also, Series might also include data labels for columns. And access by data label.

I do not see good @nogc solution for now. PRs are welcome!

Ah, I see the issue. I may just focus on generalizing the time dimension to coordinates for now.

Some other comments after spending some more time with it:
opIndexopApply documentation says

Special [] op= index-op-assign operator for time-series. Op-assigns data from r for time intersection. This and r series are assumed to be sorted.

The "for time intersection" is not entirely obvious what it means. Looking at the code and examples, it looks more like a left join. So I thought it could probably be explained a little more clearly, such as (with similar adjustments for opIndexAssign)

Special [] op= index-op-assign operator for time-series. Op-assigns data from r with time intersection. If a time index in r is not in the time index for this series, then no op-assign will take place. This and r series are assumed to be sorted.

Regardless, the behavior still seems risky to me. It may also be prudent to include a warning in the documentation that it may be useful to check that they have the same time index first. Functions to align time series would be useful.

More generally, I think the documentation on mir.ndslice.slice could use some work. Some suggestions: 1) Universal/Canonical/Contiguous link to short one line explanations in SliceKind, but the Slice struct has much more detail. Perhaps you can mention to refer to the sections of the Internal Binary Representation of Slice?

2) I have had trouble understanding this Internal Binary Representation section. a) I would recommend that the first paragraph be split in two at the "For ranges...". The first paragraph could then provide more details on lengths/strides/pointer and how that relates to the template arguments of the Struct. In particular, I find packs/strides to be among the most difficult to understand aspects based on the current documentation. b) The sections for Canonical and Contiguous do not have examples or representations like the Universal does. c) I think many would be interested in use cases for the different SliceKinds and performance implications.

3) After this section, you might use a bigger header for Examples.

4) The Definitions heading begins a discussion on operator overloading. You might instead change the heading to Operator Overloading. For instance, the table and discussion do not have definitions of other concepts, such as strides or packs, that I said above I don't think are well described (but I don't necessarily think the definitions should go here either).

5) The first line at the top really has little detail before going into the Definitions section. You might expand this a bit and provide a simple example and then have links to the different sections and what information is in each.

Reply via email to