7
$\begingroup$

I just detected that Mathematica 10.4.1 on Windows will just quietly return Null when I try to Import an .mx file I exported with version 11.1.1. I understand and know that .mx files that were generated with newer versions will generally not load with older versions. Up to now I thought (and I believe I have seen that for older verions) it would give some message and return $Failed, but obviously this is not the case here. As often, the documentation page for the MX format is not giving detailed information about that specific case.

My question is whether that is the expected behavior and whether there is some documentation about that or that would be something to report to WRI...

$\endgroup$
3
  • 2
    $\begingroup$ This seems wrong, it isn't what I get on Mac OS. If I export an mx in 11.1, and import in 10.3, then I get a $Failed and a "Import::infer: "Cannot infer format of file \!(\"test.mx\"). "" message $\endgroup$
    – Jason B.
    Commented Aug 10, 2017 at 15:33
  • $\begingroup$ @JasonB. I get that too if I just import. But if I take serious the message it only complains that it cannot infer the format. What I actually was trying is Import[filename,"MX"] because my original filename did not have the .mx extension and that is what quietly fails and returns Null, at least on Windows and with version 10.4.1. Without the format as second argument it behaves as you describe. With version 9.0.1. trying to force the "MX" format hangs the Kernel, I don't know if I like that better :-). Could you try what happens for you with the explicit "MX"? $\endgroup$ Commented Aug 10, 2017 at 19:41
  • 1
    $\begingroup$ @albert-retey_ I think you got yourself a bonafide bug right there. I can create an MX in 11.1, and if I import it in 11.0 with the format specified it will quietly return null. For safety, I would just make sure the files all have the ".mx" extension and force Import to infer the format. $\endgroup$
    – Jason B.
    Commented Aug 10, 2017 at 19:50

1 Answer 1

6
$\begingroup$

This is indeed a bug. A careless tweak was made to the format, so that MX files created by Version 11.1 or newer aren't even recognized as MX files by pre-11.1.0 versions. So Get is succeeding, reading the binary file as text and returning Null because it encounters a zero byte, interpreted as end of file, early on. If for some reason it is important to you that old versions properly recognize and reject newer MX files, you can use the program below after you DumpSave to tweak the MX file. This version will be loaded by V11.1+, and properly rejected as too new by older versions.

On the plus side, one thing we did in the forth coming 11.2 is improve cross-version compatibility of MX files. So, unless a new feature forces an incompatible change in the format, 11.2 will be able to read MX files from later versions. (Obviously, new features won't work in an older kernel).

newHeader = {40, 42, 84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 77, 
   97, 116, 104, 101, 109, 97, 116, 105, 99, 97, 32, 98, 105, 110, 97,
    114, 121, 32, 100, 117, 109, 112, 32, 102, 105, 108, 101, 46, 32, 
   73, 116, 32, 99, 97, 110, 32, 98, 101, 32, 108, 111, 97, 100, 101, 
   100, 32, 119, 105, 116, 104, 32, 71, 101, 116, 46, 42, 41};

newFooter = {40, 42, 69, 110, 100, 32, 111, 102, 32, 77, 97, 116, 104,
    101, 109, 97, 116, 105, 99, 97, 32, 98, 105, 110, 97, 114, 121, 
   32, 100, 117, 109, 112, 32, 102, 105, 108, 101, 42, 41, 0};

fixUp111PlusMX[file_] := With[{bytes = BinaryReadList[file], path = AbsoluteFileName[file]},
   BinaryWrite[path, 
   Join[newHeader, Take[bytes, {79, -49}], newFooter]];
   Close[path]
]
$\endgroup$
2
  • $\begingroup$ thanks Itai for that information, it is very valuable. Will version 11.2 also be corrected to write headers/footers so that older versions will recognize they cannot read those files? $\endgroup$ Commented Aug 11, 2017 at 10:05
  • 2
    $\begingroup$ At this point, 11.2 is still using the new header and that is unlikely to change prior to release. Beyond 11.2.0, we'll have to assess our options and determine what will cause the least amount of disruption. $\endgroup$ Commented Aug 11, 2017 at 21:14

Your Answer

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

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