Saving FittedModel is buggy

Question

With Mathematica 7 and 8 we have discovered that Mathematica fails to properly Save and Get the result of a fitting routine. I am hoping someone here knows: What is the best practice workaround for this bug?

Our task is that we are fitting lots of data sets with NonlinearModelFit, which returns a FittedModel for each data set. These fits take a while and we tried using Save and DumpSave to memorize the results to a file. Subsequent analysis uses Get to pull the FittedModel(s) back in.

Mathematica executes the Save & Get without warnings but the FittedModel that comes back is buggy. We call Get and load a FittedModel from disk, call the result "foo". Trying foo[10] evaluates the fitted model with input 10. The bug we see is that foo["BestFitParameters"] should return a list a rules but instead plugs the string into the function as it it were a number like 10. Trying foo[{"BestFitParameters","BestFitParameters"}] should give the rules twice in a list, but stays unevaluated with the buggy foo.

There is a strange and misleading behavior on top of this, depending on whether we Remove/Clear foo or quit the kernel:

• Compute the FittedModel as foo
• Save or DumpSave foo to disk
• Remove and/or Clear foo
• Get foo from disk
• foo works fine

But if we restart the kernel it fails

• Compute the FittedModel as foo
• Save or DumpSave foo to disk
• Kill and restart the kernel
• Get foo from disk
• foo is buggy

Has anyone seen this kind of behavior before?

Is there a good explanation behind this bug?

Is there a good workaround?

Answer 1

This is a known bug, and luckily there is an easy workaround. Before evaluating Get to read the saved FittedModel, evaluate a dummy fitted model code.

In[1]:= NonlinearModelFit[Range[5], a x, x, a];

In[2]:= Get[FileNameJoin[{$HomeDirectory, "Desktop", "bignlm.mx"}]];

In[3]:= AbsoluteTiming[nlm["BestFitParameters"]]

Out[3]= {17.6010000, {a -> 1.45015, b -> 2.33999}}

If this initial evaluation is skipped, the fitted model does not appear to work correctly as stated reportedly due to failure to automatically load all the dependent code that implements the functionality. The evaluation of In[1] basically forces the loading.