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