How do you name time series / table variables?

Hello community,

when having a dataset with much variables in the form of a timetable, I often name the table with its variables something like:

Data.Time
Data.temperature
Data.current

etc...

However it happens quite often, that I have a time series in the form of a timetable, which only is made from one measurement.

This makes me always wondering how I should call those variables, since I dont want the timetable be called "Data".

At the moment I am using mostly something like:

Temperature.Time
Temperature.Values % Temperature.Value? Temperature.Data? Temperature.temperature??? I hate it.

How would you name souch a timetable?

There is no "right" answer here, so my favorite one after a day or so will be accepted :)

[max]

Also why does MATLAB name the time "Time" and not "time"? The time is an array not a struct, and should be lowercase, shouldnt it?

[dpb]

I generally use a preceding lowercase 't' for a table variable and 'tt' for a timetable to remind the storage type.

I have no set rule for capitalization of variables other than try to be consistent within a given table just for sanity and appearance--with automagic name completion via the tab key, it's not that big of a deal.

I am certainly not in favor of VeryLongandVerboseandMindlessFollowingCamelCaseVariableNames, however; I am far more likely to use just tTemp or the like for the table you outline above, very likely the temperature variable inside the table will be just "T". I hate excess typing on input and imo longer names just obscure the code intent by making harder to parse the actual statement content.

[max]

My question is much about preferences....

I dont like the idea of a preceding t for a table (or nearly any kind of variable) since it is a bit to hungarian for me.

Altough it would help me when using something awfull like temperature.temperature.

A problem about names like temperature.T would also acure when combining it with a different table on the way (which in my case often happens). Than you would be forced to rename the variable...

I think I like the default var1 of a table name more than a one letter name, which just seems weird in my programming style (never having one letter variables)...

About capitalisation: I wouldnt care by myself but I want to be consistent. And since Matlab decides the time is called Time I want understand why this is the case to be consistent with my own names...

[Mario Malic]

I use lowercase camel for variables, structures, most of the stuff basically and uppercase camel for functions, properties. I switched from uppercase snake case, as that code now looks to me "harsh" to read. It all depends on the context you are programming in, especially in OOP, where it's quite good to know whether the variable is class or property or variable.

Where do you see this? Also why does MATLAB name the time "Time" and not "time"?

[dpb]

"Time" is the default name TMW chose for the time column in a timetable if the user doesn't specify a different name or use a variable of another name -- in that case it will use the user-defined name.

It's Time instead of time simply in order to be case-consistent with the capitalization convention of the default variable names being Var1, Var2, ... It would look peculiar otherwise.

[dpb]

"a one letter name, which just seems weird in my programming style (never having one letter variables)..."

You're simply too young to remember "the good old days" of keypunches and Dartmouth BASIC with at most two-letter variable names (a letter with an optional single digit).

We of that era are perhaps permanently scarred...

[dpb]

"...and uppercase for functions, properties"

Really? User functions are all UPPERCASE()??? How F77-like! ::)

About the only place I use all uppercase is for constant data arrays like for lookup tables, etc., to identify them as being invariant data (oh for an invariant data type in MATLAB a la PARAMETER or such).

[dpb]

"A problem about names like temperature.T would also acure when combining it with a different table on the way (which in my case often happens). Than you would be forced to rename the variable..."

What's the difference? If you use abracadabra for a magic variable name in some table, if it occurs in another which you're going to catenate horizontally it'll have to change, too.

Whether it is just T or whether it is temperature or Temp or whatever, unless you create totally unique names everywhere you'll run into the same issue. Hence, why not use the conventional, concise that a temperature is T; to catenate, instead of creating more variables, use arrays. There are a million threads on Answers of the problems people generate for themselves by creating series of variables as sequentially-numbered independent variables instead.

if it is the exterior temperature and another is an interior, then name them as Tint, Text or somesuch, but use the same idea of arrays of those for multiple cases or whatever, not new, independent variable names for what are, fundamentally, the same thing. This is especially true when same operations are going to be performed on the different instantiations; independent names breaks vectorized code; the whole advantage of MAT(rix)LAB(oratory).

[max]

Time being uppercase because Var1 to Varn are is not a good argument, why should any array be uppercase?

[Mario Malic]

Uppercase camel, I thought it wouldn't be necessary to add the camel because it was in the same sentence. Actually I switched to camel case because I have seen code of one of the veterans here, and thought, oh, this looks nice!

[max]

T could of corse work as an variable in my greater table, but why is the table with only The temperature called temperature? It would be two different names for the table and it’s rowname, and that is the biggest problem. Not if temperature should be called theta, T, or TemperatureThetaInKelvin

[dpb]

", why should any array be uppercase?"

Why should it NOT be uppercase? Var1 thru VarN are capitalized, surely wouldn't make sense to have only the time variable be all lowercase and the variables capitalized or vice versa. And, as Steven L notes, there's no deep hidden meaning in a variable name, anyway; it's just a name.

If you prefer some convention, you're at liberty to choose the name you want; you can update the variable names at will in the table.Properties.VariableNames cell array. As it clearly illustrates, they're just name strings associated by column position; they have no bearing other than as that reference.

And, the rowtimes name is no different; see the example:

tt=timetable;                                               % an empty table object
tt=[tt;array2timetable(rand,'RowTimes',datetime(date))];    % add a variable

>> tt                                                       % see what we gots...
tt =
  timetable
       Time         Var1  
    ___________    _______
    06-Feb-2021    0.49865
>>

rowtimes and variable names are capitalized by default.

tt.Properties.VariableNames=lower(tt.Properties.VariableNames);
tt.Properties.DimensionNames(1)=lower(tt.Properties.DimensionNames(1));

>> tt
tt =
  timetable
       time         var1  
    ___________    _______
    06-Feb-2021    0.49865
>> 

Now they're both uncapitalized; could have changed either to anything in the world wanted to be...the row times column doesn't even have to be named anything related to time:

>> tt.Properties.DimensionNames(1)={'Fred Flintstone'}
tt =
  timetable
    Fred Flintstone      var1  
    _______________    _______
    06-Feb-2021        0.49865
>> 
>> tt.('Fred Flintstone')
ans = 
  datetime
   06-Feb-2021
>> 

[max]

I just want consistensy within my code, and as far as I know, uppercase arrays are classes or structs for the most programmers.

Like I said, I dont want to change the default name for Time. Altough it is possible to do that, it is annoying. I even remember that in my use case I needed at some point extra lines of codes just to change Time to t which I started to use in the beginning of my project and got annoying quite fast. Sadly I cannot access those lines of codes, maybe I the extra line was not necessary.

However, the default is the simplest solution, that is the reason I want to use Time as my time. I just dont know why it is uppercase and if I should make all of my variables uppercase, to be consistent. Surely, some MATLAB engineer was following some guideline when naming time Time? I noticed, that variables in a struct like a figure are also uppercase, so does someone know a specific convention?

I found myself in a similar problem when using the appdesigner. MATLAB is build in a way, that it is in a few cases the best solution to use the default names given by the programm.

And since I want my code be consistent, regardless if I named the variable or MATLAB did, I want to know what the MATLAB guidelines are.

[dpb]

"I want to know what the MATLAB guidelines are."

There aren't any...the best you can do is see what the default naming convention is in any given place -- for a table or timetable, it's a capitalized name string.

Answer 1

[Steven Lord]

My advice is to name the variable that contains your timetable array something that makes sense for your application. If you're using a timetable to store the temperature measured at (for example) Boston's Logan Airport then an appropriate name might be airportTemp or Logan or even just temperatures (especially if the timetable has entries for other locations along with a variable stating where the measurements were taken.) Similarly the names of the variables in your timetable should make sense for your application. If I had that timetable of Logan Airport temperature measurements any of F (for Fahrenheit), Temp, or measurement might be appropriate names for that variable.

Don't read too much into the default name for the time dimension being Time instead of time. The name refers to time because this is a timetable not a table. And if you specify a different variable name as the times of your timetable the first dimension name may be different. Using the example from the timetable help text:

MeasurementTime = datetime({'2015-12-18 08:03:05';'2015-12-18 10:03:17';'2015-12-18 12:03:13'});
Temp = [37.3;39.1;42.3];
Pressure = [30.1;30.03;29.9];
WindSpeed = [13.4;6.5;7.3];
WindDirection = categorical({'NW';'N';'NW'});
TT = timetable(MeasurementTime,Temp,Pressure,WindSpeed,WindDirection)

TT = 3x4 timetable
      MeasurementTime       Temp    Pressure    WindSpeed    WindDirection
    ____________________    ____    ________    _________    _____________

    18-Dec-2015 08:03:05    37.3      30.1        13.4            NW      
    18-Dec-2015 10:03:17    39.1     30.03         6.5            N       
    18-Dec-2015 12:03:13    42.3      29.9         7.3            NW      

TT.Properties

ans = 
  TimetableProperties with properties:

             Description: ''
                UserData: []
          DimensionNames: {'MeasurementTime'  'Variables'}
           VariableNames: {'Temp'  'Pressure'  'WindSpeed'  'WindDirection'}
    VariableDescriptions: {}
           VariableUnits: {}
      VariableContinuity: []
                RowTimes: [3×1 datetime]
               StartTime: 18-Dec-2015 08:03:05
              SampleRate: NaN
                TimeStep: NaN
        CustomProperties: No custom properties are set.
      Use addprop and rmprop to modify CustomProperties.

The first dimension is MeasurementTime not Time. The error message you receive if you ask TT for its time data makes this clear.

TT.MeasurementTime

ans = 3×1 datetime array
   18-Dec-2015 08:03:05
   18-Dec-2015 10:03:17
   18-Dec-2015 12:03:13

TT.Time % will not work

Unrecognized timetable variable name 'Time'. If you intended to access the row times, use 'MeasurementTime' for this timetable instead.

[max]

Using a different name for the keyword „Time“ in a timetable is not that practical. I did it once in a quite big project and it often got me to problems since there are many ways to generate a timetable (table2timetable, starting with an empty timetable and after that putting values in it etc.), and the default name for the time is just „Time“. So I think I will have to use this keyword...

In your example you had a timetable with multiple variables, my problem comes from using multiple timetables with a single variable in it.

I don’t know how I should name the timetable and it’s one variable...

[dpb]

You're creating problems for yourself it would seem; one would have to see some specific code that got you into trouble to see clearly the simplest way to handle it.

Shows us the code or a simplified version of what you're trying to do that causes you grief; I can't picture it from the description alone.

[Steven Lord]

You can control the dimension names.

MeasurementTime = datetime({'2015-12-18 08:03:05';'2015-12-18 10:03:17';'2015-12-18 12:03:13'});
Temp = [37.3;39.1;42.3];
Pressure = [30.1;30.03;29.9];
WindSpeed = [13.4;6.5;7.3];
WindDirection = categorical({'NW';'N';'NW'});
TT = timetable(MeasurementTime,Temp,Pressure,WindSpeed,WindDirection)

TT = 3x4 timetable
      MeasurementTime       Temp    Pressure    WindSpeed    WindDirection
    ____________________    ____    ________    _________    _____________

    18-Dec-2015 08:03:05    37.3      30.1        13.4            NW      
    18-Dec-2015 10:03:17    39.1     30.03         6.5            N       
    18-Dec-2015 12:03:13    42.3      29.9         7.3            NW      

TT.MeasurementTime

ans = 3×1 datetime array
   18-Dec-2015 08:03:05
   18-Dec-2015 10:03:17
   18-Dec-2015 12:03:13

TT.Properties.DimensionNames{1} = 'When'

TT = 3x4 timetable
            When            Temp    Pressure    WindSpeed    WindDirection
    ____________________    ____    ________    _________    _____________

    18-Dec-2015 08:03:05    37.3      30.1        13.4            NW      
    18-Dec-2015 10:03:17    39.1     30.03         6.5            N       
    18-Dec-2015 12:03:13    42.3      29.9         7.3            NW      

TT.When

ans = 3×1 datetime array
   18-Dec-2015 08:03:05
   18-Dec-2015 10:03:17
   18-Dec-2015 12:03:13

The second element of the DimensionNames is what you would use to extract all the data as a matrix, but since you can't create a matrix with both double (Temp, Pressure,WindSpeed) and categorical (WindDirection) data I can't show that in this example. By default is is 'Variables' but if my timetable had just the double variables a better name for it might be WeatherData and after I set that as DimensionNames{2] then I could ask for TT.WeatherData.

So build your timetable however you want then tell MATLAB to give it the name of the times that is most appropriate for your specific application.

As for multiple timetable arrays each with one variable, if that makes sense for your problem use that approach. If they're related you might want to combine them into one timetable with each of the variables from the individual arrays as a variable in the joined array. The synchronize function for timetable arrays will help you combine them and handle potential mismatches in the time bases for each single-variable array.

[max]

"You're creating problems for yourself it would seem; one would have to see some specific code that got you into trouble to see clearly the simplest way to handle it."

I will try to give a good example. To the answer of lord: I have multiple single variable timetables in my programm because they were measured that way. Even if I combine them, I will have had the naming problem at some point.

%% Skript does prepare the measured data
% read three different measurements, all of them having their
% own time and are saved as arrays in rawdata
rawdata = readdata

temperature = timetable(minutes(rawdata{1}), rawdata{2})
pressure = timetable(datetime(rawdata{3}), rawdata{4})
% ...

I use timetables for temperature and pressure, because they are convenient to use. In my scenario lets say I dont want combine them. How should I name the timetables and its variables?

[Steven Lord]

Let's make some arbitrary data.

v = 0:0.5:10;
rawdata = {(1:5).', 40 + randi([-10 10], 5, 1), ...
    reshape(v(randperm(numel(v), 8)), 8, 1), 1 + randn(8, 1)};
temperature = timetable(minutes(rawdata{1}), rawdata{2})

temperature = 5x1 timetable
    Time     Var1
    _____    ____

    1 min     33 
    2 min     37 
    3 min     40 
    4 min     49 
    5 min     30 

pressure = timetable(minutes(rawdata{3}), rawdata{4})

pressure = 8x1 timetable
     Time        Var1  
    _______    ________

    8 min       0.94519
    1.5 min      2.1517
    6 min        1.7082
    3.5 min      2.2478
    4.5 min      1.4795
    3 min        1.1954
    0 min      -0.25179
    9 min        1.2803

The names of the two arrays seem reasonable, temperature and pressure. I assume you're asking what you should name the variables with the default name of Var1 in each of these arrays? What makes sense for your application. If those temperature measurements were for the temperature outside (during a New England winter day, the temperature can fluctuate wildly but not usually that wildly!) maybe:

temperature.Properties.VariableNames{1} = 'outside temp'

temperature = 5x1 timetable
    Time     outside temp
    _____    ____________

    1 min         33     
    2 min         37     
    3 min         40     
    4 min         49     
    5 min         30     

You might also want to give it a unit for use when the timetable is summarized.

temperature.Properties.VariableUnits{1} = 'degrees F'

temperature = 5x1 timetable
    Time     outside temp
    _____    ____________

    1 min         33     
    2 min         37     
    3 min         40     
    4 min         49     
    5 min         30     

summary(temperature)

RowTimes:

    Time: 5x1 duration
        Values:
            Min           1 min 
            Median        3 min 
            Max           5 min 
            TimeStep      1 min 

Variables:

    outside temp: 5x1 double

        Properties:
            Units:  degrees F
        Values:

            Min          30   
            Median       37   
            Max          49   

It sounds a little like you're looking for Absolute Rules of Variable Naming in MATLAB, inscribed on tablets brought down from On High (one of the offices on the top floor of our Apple Hill headquarters.) Those don't exist.

Well, okay there are some rules you can't violate for standalone variable names (see the isvarname function for that list.) However some of those rules don't apply (anymore) to variable names inside a table ('outside temp' is not a valid standalone variable name as it contains a space but is allowed as of a recent release as a table variable name.)

As guidelines I would say:

1. Make your variable names meaningful. Ideally you shouldn't have to explain what your data represents to someone who has read the variable names. The more your code / data explains, the less time you have to take explaining it to others and the more time you can spend working with your code / data.
2. Make your variable names as long as they need to be, no longer and no shorter.
3. Be consistent within your code. Don't use temp one place, Temp another, and tEmP a third. [Personally I'd advise you not to use that third one at all.]
4. If appropriate be consistent with others' code as well, especially if you need your code / data to interface with theirs.

[dpb]

"... let's say I don't want combine them. How should I name the timetables and its variables?"

Again, w/o more details of what you're going to be doing with them, if it really is reasonable to not combine tables, I'd suggest an array of tables would be a practical solution to solve both naming problems of what the table(s) are named as well as the internal variable(s).

Personally, given my preference for coding style, I'd almost certainly combine the tables unless the times are inconsistent and there never will be a wish to synchronize them but treat them all as totally independent.