JuliaStats
Should meta be a dict?
The possibility of changing a meta value that I set by string concat makes recovering my information more involved -- and having meta be a dict allows all sorts of useful contextual information to be preserved (data source, any series transform, app-specific categorization ...).
The reason I went with Any is because though Dict seems a natural fit, there are cases (that I had explored) where you might want it to be a custom type.
I can see that -- would this work for you
# custom type for special purpose
julia> const CustomType = AbstractVector{S} where S<:Set{A} where A
AbstractArray{T,1} where T<:Set{A} where A
# special purpose function
function special(x::CustomType)
return union.(x...)
end
# test
special(Set([1, 2, 5]), Set([5, 7, 2]))
Set([1, 2, 5, 7])
# default empty initialization
julia> meta = Dict{Any,Any}}([ :meta => nothing ])
Dict{Any, Any} with 1 entry:
:meta => nothing
julia> meta[:meta] = CustomType
AbstractArray{T,1} where T<:Set{A} where A
allowing the dictionary key :meta to retain the developer's right to do something wonderful
while providing an integral means of carrying important context through multiple key,value pairs
I think this would elevate the ease of multiuse for TimeSeries -- and I would put together a PR implementing that change iff the participants were inclined to move in this direction.
Alternatively, if your solutions are more elegant with TimeArrays able to carry custom type realizations that are more immediately given than within a dict, I would rather give you that as a new field that usually holds nothing (unless the type realization is of some special nature). There is a long history of timeseries data files becoming estranged from their original context and utilization. Having the ability to keep datasource, raw_or_cleaned, levels|diffs|logs, and even annotations covering analytic impressions all together with the data per se is a big win.
@JeffreySarnoff says
There is a long history of timeseries data files becoming estranged from their
original context and utilization
I completely agree.
You mention you are will to do this PR and I think it's worth creating a sandbox (branch) for it, that way we can better see the benefits of your approach.
If you don't mind to do a PR for a new branch that would be awesome.
I want the technology, so PR ahead. Just one question: how do I make a PR for a sandbox? ? make a new branch here "sandbox" and keep it current with any next commits to master then I will fork the repo and make my edits to sandbox and PR from that branch? (how do I ensure that my sandbox is uptodate with master's branch sandbox as I write?)
@milktrader do you prefer a new field (named custom or internal (which? other?)) or does using a preassigned dict key (:custom or :internal) for that purpose just as good?
For the custom field, do you intend this?
retype
The retype field defaults to holding nothing, which is represented by type Void. This default is designed to allow programmers to ignore this field. For those who wish to utilize this field, retype can hold variants of type TimeArray that introduce capabilities or provide perspectives that are not available with the exported TimeArray type. ta.retype(ta) should return a well-constructed and properly elaborated subtype of AbstractTimeSeries.
As far as a PR, since this is your project call it whatever you want. You create one locally with git checkout -b my_cool_name.
excellent
On Mon, Jun 12, 2017 at 7:26 AM, milktrader [email protected] wrote:
To update your experimental branch, @ararslan https://github.com/ararslan provides the git-fu here https://github.com/JuliaStats/TimeSeries.jl/issues/300#issuecomment-287117201
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JuliaStats/TimeSeries.jl/issues/316#issuecomment-307762807, or mute the thread https://github.com/notifications/unsubscribe-auth/ABmqxiTlhpMyOQc4loA4Qxz1xGEkgkRtks5sDSBygaJpZM4N0rXH .