Having developed a substantial code base in Mathematica 9, leads me to ask these important questions prior to downloading and installing Mathematica 10.

Will any Mathematica functions from the previous version either not work in Mathematica 10 or work differently?

If so, does anyone know of a reference to such changes?

I've looked for one but only find the new features.

  • 2
    $\begingroup$ Shouldn't this be in meta? $\endgroup$
    – Öskå
    Commented Jul 10, 2014 at 17:31
  • 1
    $\begingroup$ Compatibility is usually pretty good, but there's always a small chance that something has changed in a breaking way. There's no list of such changes. The best way to test is to run your code. I recommend that you have M9 and M10 installed side by side (easy and possible) until you are confident that nothing critical got broken in 10. $\endgroup$
    – Szabolcs
    Commented Jul 10, 2014 at 17:33
  • 1
    $\begingroup$ @Öskå - Happy to see this moved to Meta if everyone thinks it makes more sense there. $\endgroup$
    – Jagra
    Commented Jul 10, 2014 at 17:44
  • 2
    $\begingroup$ "I just still remember a version change where all sorts of functions no longer worked." That might have been the introduction of the completely revamped graphics system in version 6. (You could still load the old behavior with << Version5`Graphics` .) Does that sound right? $\endgroup$
    – Mr.Wizard
    Commented Jul 10, 2014 at 18:27
  • 5
    $\begingroup$ @Öskå Meta is for questions about this site rather than Mathematica itself, therefore this question is more appropriate here on the main site. $\endgroup$
    – Mr.Wizard
    Commented Jul 10, 2014 at 19:22

6 Answers 6


Multiple versions of Mathematica can co-exist on a computer without problems. The best approach is to have both version 10 and version 9 installed simultaneously until you are confident that all your critical code work with 10.

When using multiple versions it is useful to go to Preferences -> System and check "Create and maintain version specific front end preferences".

It is also good practice to check the kernel init.m after upgrading, if you have ever changed it, especially if you put anything like this there and forgot about it.

That said, Mathematica generally aims for good backwards compatibility. Since version 6 there haven't been any major breaking changes. The most likely source of conflict is the introduction of new names. For example, many people defined Norm before version 5 introduced a builtin of the same name. This is why it is good practice never to use names starting with capital letters: this guarantees that newly introduced names in future versions won't break older code. (This guideline doesn't apply to packages, which should put everything in a separate context to avoid name conflicts. In fact it's better to use capitalized names in packages for the same reason: avoid conflict with notebook code that doesn't have its own namespace.)

The documentation has some information about which functions have changed and how. The version when the function was last changed is shown at the bottom:

Changes in the last version can be highlighted:

This information should not be considered 100% accurate. There may be accidental omissions. Some changes may not be noted. (Though these are less likely to be breaking changes.)

The default plotting styles have changed in Mathematica 10. If you have notebooks for generating publication figures, they will not produce the same output any more.

It is not only the colours and thicknesses that have changed, but e.g. ListPlot now produces dots with a relative size specification, so they scale with the figure (before it was absolute and the dots didn't scale). This has affected me personally, but the fix was easy.

It should be possible to revert to the old styles by using the option PlotTheme -> "Classic" in plotting functions, or using the global setting

$PlotTheme = "Classic"

I do not know if this setting reverts all styles fully or not.


  • PlotTheme -> None may be a better choice than "Classic", e.g. here. This won't reset the font (which will be controlled by the default sans-serif stylesheet).

  • For 3D graphics, "ClassicLights" needs to be used, e.g. PlotTheme -> {"Classic", "ClassicLights"}. (Thanks to kguler.)

As Bezewy notes, some functions, in particular date handling functions, have different return types. DateDifference returns a Quantity object, i.e. the units (days) are included. This can be converted back using QuantityMagnitude.

DatePlus, DateRange, etc. will return DateObject instead of a date list only if the input is also a DateObject. So this shouldn't break old code.

DateObject can be converted back to the old form (a date list) using Normal.

(* {2014, 7, 12, 0, 0, 0.} *)

Using Normal for this conversion is more convenient than using DateList because it will convert every DateObject in the expression. For example, we can do Normal@DateRange[Today, DatePlus[Today, 10]].

  • $\begingroup$ It seems that other (probably better) way to revert to the old styles is $PlotTheme = None. $\endgroup$ Commented Jul 11, 2014 at 18:26
  • $\begingroup$ @Alexey Why do you think it's better? If there's something that works better with None, I'd like to know too. None doesn't revert the fonts to Times, while "Classic" does. $\endgroup$
    – Szabolcs
    Commented Jul 11, 2014 at 18:43
  • 1
    $\begingroup$ I feel that None is just the lesser-surprise option but I have not investigated it in depth. This option looks like disabling the new $PlotTheme functionality which makes the trouble. $\endgroup$ Commented Jul 11, 2014 at 19:03
  • 1
    $\begingroup$ @Alexey You're right, here's why $\endgroup$
    – Szabolcs
    Commented Jul 11, 2014 at 23:21
  • $\begingroup$ Using SetSystemOptions["DataOptions" -> "ReturnQuantities" -> False] you can get back the old behaviour of DateDifference (trick from the 'Possible Issues' section). $\endgroup$ Commented Jul 14, 2014 at 13:14

Some functions have new return types in MM10. For instance, I'm running into trouble with date functions (like DatePlus) since they return DateObjects in MM10 but returned date lists in MM9. Other functions (like DateDifference) now return Quantity objects instead of a number.

  • $\begingroup$ can you please post small example? $\endgroup$
    – Nasser
    Commented Jul 10, 2014 at 18:19
  • $\begingroup$ DateDifference[{2014, 1, 1}, {2014, 1, 2}] == 1 returns True in MM9 but 1 day == 1 in MM10. As for DatePlus, looks like it's not a compatibility problem after all since it only returns a DateObject if given a DateObject. $\endgroup$
    – Bezewy
    Commented Jul 10, 2014 at 18:54
  • $\begingroup$ If the Wolframians keep up the standards they honored until now, then I expect my version 4.0 code to still live and kick as it does in in version 9.0. Minor modifications like dropping 'GraphicsArray' are to be taken in the stride. So, I'm positive about downward compatibility. $\endgroup$
    – Wouter
    Commented Jul 10, 2014 at 18:58
  • 2
    $\begingroup$ It seems the added Quantity to the result. So now one needs to do DateDifference[{2014, 1, 1}, {2014, 1, 2}] == Quantity[1, "Day"] which returns True $\endgroup$
    – Nasser
    Commented Jul 10, 2014 at 19:06
  • 3
    $\begingroup$ Using SetSystemOptions["DataOptions" -> "ReturnQuantities" -> False] you can get back the old behaviour of DateDifference (trick from the 'Possible Issues' section). $\endgroup$ Commented Jul 14, 2014 at 13:13

One difference I just run into is Dispatch. To get the original rules, use First@Dispatch[•••] in v9, but Normal@Dispatch[•••] in v10.


I wanted to let everyone know what happened to me in case it prevents the stress I'm feeling right now. I was worried about the changes in the way dates are handled as I have many lines of code with date features as I am backtesting investments. I decided to see what happens and if I could fix any issues with great inputs above.

I made sure not to uninstall version 9 so I figured it was a safe test. Well, I could not figure out how to easily fix all my date commands with "Normal@" unfortunately. It did work for some of them. So anyway I was very disappointed that installing 10 corrupted my version 9 date commands breaking my script even on version 9! No, a reboot did not reset this, and I did not save any changes on my working script.

So now my script is broken and I have to produce data in a couple weeks, and this is not my day job. I guess I will try uninstalling everything and reinstalling only 9 so I can sleep at night. Be careful out there trying out 10 if you have deadlines to meet. I don't like to post negative comments but I also don't want someone else to go through what I did. Installing 10 should not mess with 9 but it did in my case. They need to fix this.


Each new release of Mathematica, from V6 on at least, has come with a compatibility checker that intervenes each time you open a notebook created in an earlier version and warns you of code that it thinks might break because of revisions to functions that were part of previous releases. I don't have V10 yet, but I would expect it to a compatibility checker, too. Perhaps someone who has already obtain V10 can confirm this.


My personal experience of opening a version 9 notebook in version 10 had no such warnings at all, that I could see. Also I looked for compatibility checker and found none. It could exist but I didn't find it.

When I had an issue with version 9 being corrupted by V10 install, system restore did not fix the issue to my wide eyed amazement. Also, uninstalling both versions and reinstalling only 9 did not work! The same notebook opened on another computer with version 9 ran fine. Difference is that system never had 10 installed. Very strange.


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.