I have a couple of big lists (each of them contains elements that are themselves lists of two elements, i.e. an element of each list that I have is of the form {x, y}) that I want to save/export. Their generation namely takes hours, and I don't want to do this every single day.

I looked at the Mathematica help section on this (http://reference.wolfram.com/mathematica/tutorial/ImportingAndExportingData.html), but found that if I follow the example, I can't just import the data back into a list as it was before. It just ends up being something really messy.

So given such a list, say, list = {{1,2}, {1,3}, ... , {500, 500}}, what do I do, so that the next day I can just write list = Import[...]?

  • 3
    $\begingroup$ I'd use .mx files (Export / Import in "MX" format). This is fast, and does not really involve serialization / parsing in the usual sense (via strings). In other words, mx files bypass the high-level parsing, populating internal structures at lower level. In addition, mx files preserve packed arrays. $\endgroup$ Jun 24, 2014 at 21:20
  • $\begingroup$ @LeonidShifrin, yes! This works perfectly! If you make it an answer, I'd be glad to accept it. How did you figure this out, by the way? $\endgroup$
    – Ryker
    Jun 24, 2014 at 21:55
  • $\begingroup$ Actually, I recall now that I first learned about the fact that Export / Import working on .mx files from @Szabolcs. $\endgroup$ Jun 24, 2014 at 22:06
  • 1
    $\begingroup$ I find this Q&A relevant and handy. $\endgroup$
    – Johu
    Jun 25, 2014 at 0:15
  • $\begingroup$ @Johu, thanks, I'll take a closer look it when I have the time. $\endgroup$
    – Ryker
    Jun 25, 2014 at 2:53

4 Answers 4


I'd use .mx files (Export / Import in "MX" format):




This is fast, and does not really involve serialization / parsing in the usual sense (via strings). In other words, mx files bypass the high-level parsing, populating internal structures at lower level. In addition, mx files preserve packed arrays.

  • 3
    $\begingroup$ I didn't mention MX on purpose because I thought it was overkill for relatively small strictly tabular data, and it does have some dangers that are important to be mentioned: it's not cross platform (before v10) and it's not compatible between different versions of Mathematica. I'm commenting just to warn the OP and make sure he doesn't use it for archiving or doesn't try to move files between say, Windows and Linux. $\endgroup$
    – Szabolcs
    Jun 24, 2014 at 22:06
  • $\begingroup$ @Szabolcs Yep, I do realize. Just when you posted this one, I added a comment under the main question, acknowledging that I learned about Export / Import working on .mx files from you. In this particular case, however, the OP's goal seems to be saving data for later use on the same machine, thus this suggestion. $\endgroup$ Jun 24, 2014 at 22:08
  • $\begingroup$ Might comment was really aimed at the OP, not you. Yes, I agree than in general for saving important session data MX is best. Some systems like R even have a feature to restore the complete workspace, this is similar to that. $\endgroup$
    – Szabolcs
    Jun 24, 2014 at 22:11
  • $\begingroup$ @Szabolcs I disagree however that this is an overkill w.r.t. exporting as Table. The latter involves high-level serialization / parsing, and that always increases chances to not get the same thing back. Serializing to a binary format like .mx is different. $\endgroup$ Jun 24, 2014 at 22:12
  • 1
    $\begingroup$ @Szabolcs, Looks like v10 .mx files written by DumpSave and Import are not cross-platform either. That's kind of a bummer in my opinion. $\endgroup$
    – kale
    Jun 25, 2014 at 1:38

I provide two ways:

1) Human readable

data1 = RandomInteger[100, {25, 25}];
data2 = RandomReal[100, {25, 25}];
Save["humanReadable.m", {data1, data2}];

Unset[{data1, data2}]
Dimensions@{data1, data2}

{2, 25, 25}

Note, that you can dump many different variables with ease, and the file is in easy to read Mathematica syntax allowing all kinds of symbolic and numeric data without any manual serialisation. By default Save appends which can be convenient, but ofc. must be kept in mind.

Saving the data from other sources in such format might be very handy, as you can use all of the Mathematica syntax including comments. For example I use it for measurement control software data dump.

2) Platform independent binary

Obviously the upside of binary format is smaller file size and loading time in case of big data.

In addition to mx data format already discussed, there is version and platform independend format wdx. Again there is a way to export and import it with symbol names attached.

DumpSave["platformIndependendBinary.wdx", {data1, data2}];
Unset[{data1, data2}]

And if you don't want to fix / remember the variable names you can

Export["platformIndependendBinary.wdx", {data1, data2}]
Unset[{data1, data2}]
{data1, data2} = Import["platformIndependendBinary.wdx"];

The same method works for .m files for human readable text format.

The only downside of wdx compared to mx is speed.

  • 5
    $\begingroup$ WDX is awfully slow though. I use Export[..., Compress[expr], "String"], which is also version/platform independent, and faster than WDX. $\endgroup$
    – Szabolcs
    Jun 25, 2014 at 0:20
  • $\begingroup$ +1 for nice tip. The discussion about the speed I already stumbled upon and linked. $\endgroup$
    – Johu
    Jun 25, 2014 at 0:21

Probably the best way is to do

Export["mydata.txt", list, "Table"]

then later

Import["mydata.txt", "Table"]

Be sure to explicitly specify the data format: "Table". Otherwise Import/Export will likely still succeed but will automatically choose a different format.

This writes a whitespace separated plain text file that is readable by may other programs than Mathematica. If your dataset is so large that import/export takes too long, let me know, as there are better formats for that situation.

  • $\begingroup$ I just tried it, but it doesn't work as I want it to. I namely don't get the original list if I do Import["mydata.txt"]. $\endgroup$
    – Ryker
    Jun 24, 2014 at 21:53
  • $\begingroup$ @Ryker For a list of the form you mentioned, it always works for me. Please post a short example list you have, then we can figure out why we see different behaviour. $\endgroup$
    – Szabolcs
    Jun 24, 2014 at 22:03
  • $\begingroup$ Well, for example, list = {{1,2}, {1,3}}. $\endgroup$
    – Ryker
    Jun 24, 2014 at 22:28
  • 1
    $\begingroup$ @Ryker dropbox.com/s/ichx99uq4sdlujv/… $\endgroup$
    – Szabolcs
    Jun 24, 2014 at 22:29
  • 1
    $\begingroup$ @Ryker Computers store floating point numbers in a binary representation. When converting these numbers to a decimal representation, you would usually need a very high number of decimal digits to preserve the numbers precisely. An extreme example with base 3 (not base 2) that will illustrates well what happens: 0.1 in base 3 is 1/3 precisely. However, 1/3 is not even representable in decimal with a finite number of digits. Binary numbers are representable in decimal, but a perfect representation might take many more decimal digits than is reasonable to store. $\endgroup$
    – Szabolcs
    Jun 25, 2014 at 17:19

It is very easy. Save your file in .csv format e.g. Export["file.csv", data];, where data is like, data={{1.,1.},{2.,2.},{..}}. Then,during later use, initialize a list like, c={{0.,0.}} and then c = Import["file.csv"].


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.