Mir Algorithm v0.5.8: Interpolation, Timeseries and 17 new functions
jmh530 via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Tue May 9 13:35:18 PDT 2017
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.
More information about the Digitalmars-d-announce
mailing list