Timetables not fully supported by plot tools?

Hello,

I am just wondering why when plotting a timetable with duration as time axis, The "basic fitting" and "data statistics" tool in plot windos are not available.

Does this mean that timetables have some limitations compared to arrays or tables? I am asking because I need to decide if timetable is the right data structure for my use case. Basically I am importing some measuremet datas from sensors acquisition which have timestamps. In the past I would have just used plain arrays, but I see that in modern Matlab timetables are somehow suggested for these use cases.

Answer 1

[dpb]

The issue isn't with the timetable itself but in the extensions added to the plotting figure haven't been updated to include them. Never using those, I hadn't noticed .. I don't suppose the regular table is available, either.

There are some features such as retime that are only available with timetables that does make them handy for coding with, but if the interaction with the plot itself is a required feature, you'll have to use some other mechanism or extract the data from the timetable prior to plotting.

Would seem worthy of submitting an enhancement request...

[Luca]

Thanks a lot for your answer.

No, indeed I don't need this feature but I was just wondering if there are general limitations in the usage of timetables compared to matrix/arrays.

Do you think that representing time domain signals is a "correct" usage of timetables? Take into account that I will probly need to use them as input in Simulink as well.

Thanks in advance

[dpb]

"...[is] representing time domain signals is a "correct" usage of timetables?"

Well, given a timetable is a set of times with associated data to go with the observations, it appears intended to be used for precisely such things.

I would say it is more a question of what one intends to do with the data; if features specifically implemented for the timetable data class such as retime mentioned before would be helpful it would seem a reasonable fit.

OTOH, if we're talking about highspeed signal processing data acquisition kinds of application, it is probably not the ideal use case. There is another timeseries data class intended for sampled data although I've not found it convenient for my usage; there are features in it that may be of interest for certain tasks.

As for using with Simulink, I don't know a thing about it -- I'd guess interaction there would probably be simpler with simple arrays, but again I suspect it may matter as to what interaction is needed.

Answer 2

[Steven Lord]

Let's say that with basic fitting, you wanted to fit a quadratic (y = a(1)*x^2+a(2)*x+a(3)) to your data. If the x data was double, this would be possible.

v = 0:5

v = 1×6

0 1 2 3 4 5

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

y = polyval([1 2 3], v) % a would be [1 2 3]

y = 1×6

3 6 11 18 27 38

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

A = polyfit(v, y, 2) % check that it is [1 2 3]

A = 1×3

1.0000 2.0000 3.0000

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

But with duration data for x, let's do a unit analysis. How would you add x^2 (with units of hours squared), x (with units of hours), and a constant together? I suppose you could make the constant a(1) be unitless, a(2) have units of hours, and a(3) have units of hours squared (which would require y to have units of hours squared) but then you couldn't store them all in one array.

In fact, the power operators aren't defined for duration data. Neither is the times operator where both operands are duration arrays. We don't let you make duration data with units of hours squared.

x = hours(v)

x = 1×6 duration array
   0 hr   1 hr   2 hr   3 hr   4 hr   5 hr

try
    z = x.^2
catch ME
    fprintf("Error: %s", ME.message)
end

Error: Invalid data type. Argument must be numeric, char, or logical.

x2 = hours([1 2; 3 4]);
try    
    z = x2^2
catch ME
    fprintf("Error: %s", ME.message)
end

Error: Undefined function 'double' for input arguments of type 'duration'. To convert from durations to numeric, use the SECONDS, MINUTES, HOURS, DAYS, or YEARS functions.

try
    z = x.*x
catch ME
    fprintf("Error: %s", ME.message)
end

Error: Multiplication is not defined between two duration arrays.

So IMO it doesn't conceptually make sense to do basic fitting with date and time data.

The data statistics functionality could probably work with duration data. I haven't thought it completely through to identify any sticking points. My guess is that there haven't been (very many if any) requests for that tool to support datetime and duration data, so it hasn't been a priority.

[dpb]

"...doesn't conceptually make sense to do basic fitting with date and time data."

From fit examples...

load census
f=fit(cdate,pop,'poly2')            % 2nd order poly in time

f = 
     Linear model Poly2:
     f(x) = p1*x^2 + p2*x + p3
     Coefficients (with 95% confidence bounds):
       p1 =    0.006541  (0.006124, 0.006958)
       p2 =      -23.51  (-25.09, -21.93)
       p3 =   2.113e+04  (1.964e+04, 2.262e+04)

subplot(3,1,1)
plot(f,cdate,pop)
xlabel('Year'), ylabel('Population')
xl1=xlim;
dur=cdate-cdate(1);
f=fit(dur,pop,'poly2')   % 2nd order poly in duration

f = 
     Linear model Poly2:
     f(x) = p1*x^2 + p2*x + p3
     Coefficients (with 95% confidence bounds):
       p1 =    0.006541  (0.006124, 0.006958)
       p2 =     -0.0925  (-0.1789, -0.006128)
       p3 =       5.583  (1.856, 9.311)

subplot(3,1,2)
plot(f,dur,pop)
xlim(xl1-cdate(1))
xlabel('Duration (Years)'), ylabel('Population')

Nothing conceptually wrong in fitting data against time values or even powers of times/durations. Simply must have tools that know how to handle a numeric representation -- here they're in doubles, of course, but one could explicitly use a duration and cast it back or the alternative of using the venerable datenum.

subplot(3,1,3)
d=years(cdate-cdate(1));
b=polyfit(years(d),pop,2);
plot(years(d),polyval(b,years(d)),'.-','markersize',10)

As for the dimensional analysis, it's no different conceptually than fitting against a temperature or any other physical unit as is done all the time -- of course the coefficients have corresponding inverse units of whatever is the output variable's unit over the corresponding power units of the term. Many well known correlations aren't even limited to using integral powers.

The issue is simply that Mathworks has not chosen to extend the datetime or duration classes to full numeric status; this is at least understandable given the representations aren't simple doubles, but it's one of implementation detail and extending all the other tools to handle the case, not a conceptual limitation. The workaround is that one must cast either class back into a standard numeric form that the tools can handle and in general hope the double has sufficient precision compared to the datetime/duration.

[Luca]

Yes,

it perfectly makes sense. Thank you for your observation.

I still have some doubts whether I should store my data acqusiations with timetables; as mentioned, in the past I would have simply used numerical arrays but when I saw this "new" datatype I thought it was making sense to have a data structure with embedded timing information. But looking the examples, it seems to be more suited for data science tasks than classical signal processing / control systems stuff.

[dpb]

I posted some thoughts on that topic above -- I agree that if it is classic signal processing, particularly with fixed-rate sampling the array is likely a better choice although as noted there, there is the specific timeseries data class as well although it seems oriented towards events handling.