TimeSeriesAPI¶

Things that sucked at old TimeSeries datatype¶

• Strict timestamp constraint
  • Critical when appending frenquently with local-time
• No coherent abstraction for one 'entry'
• boost::ptime as mandatory timestamp-type very expensive
• restricted to RealVectorPtr values
• attach vs. append naming (concat)
• interpolation logic fails semantically for certain data types (e.g. 'rotations')
• No iterators

Things that were important in old TimeSeries datatype¶

• map function
• XML Serialization
• Plain file persistency
• 'logging' possible with 'local-time append'

Possible Improvements¶

• Explicit 'local-time' append
  • Append 'Generator' for timestamps (e.g. 'now' or 'plus x seconds')
• Implement Duration logic: values 'valid' for a certain time (relative)
• Idea for 'simpler' append operations: use typesafe offset-type similar to Dimension in MathVector/Matrix
  

  series.append(offset(DurationType), ValueType)
   ^= series.append( timestamps[length()-1] + DurationType, ValueType)  if  !isEmpty()
   ^= series.append( TimestampType() + DurationType ), ValueType)       else
  

  For instance when using boost::ptime this would take away the need to manually keep time and increment it when creating a timeseries
  • This could also resolve the issue of appending one series to another one, when timestamps need to be shifted

nemo::TimeSeries issues¶

• Vector dimensions constrainable????
• Default TimestampType pretty useless
  • Use no default and switch ordering of template params <TimeStamp,Value>
• operator[] ?????
  • Current 'compromise'
  • operator[] only for reading
  • Split index-access into separated timestamps/values accessors
    

    ts = series.timestamps[index]
    series.timestamps.set(index, ts)
    
    val = series.values[index]
    series.values.set(index, val)
    
    val = series[ts]
    series.set(ts, val)
    

    • Nice because: index- and timestamp-based access is nicely separated
    • Nice because: each view plus the full series can provide a coherent Collection and STL-iterator interface
  • Possible future way for write access: ReadWriteRef logic like in MathVector
    

    vectorSeries.values[i] = vector
    vector = vectorSeries.values[i]
    ((Vector)vectorSeries.values[i]).vectorMember()
    

  • The only problem: member calls not transparently possible
    

    vectorSeries.values[i].vectorMember() // compile error through ReadWriteRef
    

  • Rejected alternative: make datatype non-copy-on-write and let [] return non-const reference
    • Both writing and member-access possible
    • Big problem: one doesn't notice when a timestamp is changed is way that requires re-sorting