What is the best file format to import data into Matlab?

What will be the most robust file format when one tries to import data into Matlab?

[dpb]

For what definition of "robust" of what kind of data?

[alpedhuez]

Sort of make sense that xls is proprietary so that it can be more stable: csv has all these variations like encoding that can confuse Matlab

Answer 1

[Image Analyst]

I'd perhaps offer .mat file. Since the .mat file is MATLAB's own proprietary format, it's arguably the best for importing stuff into MATLAB. However that assumes that whatever program you are exporting your data from can create a .mat file. If it's MATLAB, then great, no problem. If your program cannot create .mat files, then you're out of luck. In fact if your program outputs some proprietary format, you may have to write your own reader for it. If it's a standard format like .xlsx, .PNG, etc. then that's probably somewhat robust. But if they do something tricky with it, like they often do with .csv files by putting weird header lines in them, then the standard reader in MATLAB may not work.

[alpedhuez]

1. Open file using import tool

2. Save the table with .mat format

3. Read the table and work with it.

Answer 2

[Walter Roberson]

plain text has a lot to be said for it, in that if one tool somehow does not work there are a lot of possibilities for going back and using other tools or using textscan() or the like.

However, plain text does not handle hierarchies of data well, so you start to need structured text -- but then you start to become reliant on the tools that handle that structure.

Plain text is not the fastest. Note that xlsx files are plain text internally, so they are slower than binary files -- but have the advantage that there are a lot of tools to examine and process xlsx files.

Dates and times are a perpetual challenge, because people outputting them often ignore questions about whether the times were local according to "summer time" in effect, and if so what were the transition dates that year, and were leap seconds included, and what is the available time resolution, and what timezone are the in, and what is the base of the calendar (e.g., georgian vs gregorian), and whether the times are Earth based or solar times, and so on. The time needs for GPS purposes are not the same as ordinary human times...