How do you name time series / table variables?
Afficher commentaires plus anciens
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 :)
14 commentaires
Maximilian Schönau
le 5 Fév 2021
dpb
le 5 Fév 2021
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.
Maximilian Schönau
le 5 Fév 2021
Mario Malic
le 5 Fév 2021
Modifié(e) : Mario Malic
le 6 Fév 2021
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"?
"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.
"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...
"...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
le 6 Fév 2021
"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).
Maximilian Schönau
le 6 Fév 2021
Mario Malic
le 6 Fév 2021
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!
Maximilian Schönau
le 6 Fév 2021
Modifié(e) : Maximilian Schönau
le 6 Fév 2021
", 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
>>
Maximilian Schönau
le 6 Fév 2021
Réponse acceptée
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.Properties
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
TT.Time % will not work
6 commentaires
Maximilian Schönau
le 6 Fév 2021
dpb
le 6 Fév 2021
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.
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.MeasurementTime
TT.Properties.DimensionNames{1} = 'When'
TT.When
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.
Maximilian Schönau
le 6 Fév 2021
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})
pressure = timetable(minutes(rawdata{3}), rawdata{4})
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'
You might also want to give it a unit for use when the timetable is summarized.
temperature.Properties.VariableUnits{1} = 'degrees F'
summary(temperature)
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:
- 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.
- Make your variable names as long as they need to be, no longer and no shorter.
- 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.]
- If appropriate be consistent with others' code as well, especially if you need your code / data to interface with theirs.
dpb
le 6 Fév 2021
"... 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.
Plus de réponses (0)
Catégories
En savoir plus sur Data Type Identification dans Centre d'aide et File Exchange
le 5 Fév 2021
le 7 Fév 2021
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
