83

There is documentation of the incompatible changes made to Mathematica with each major release:

Unfortunately that documentation simply stopped with version 7. Therefore I ask:

What incompatible changes have been made since Mathematica 7?

There are other questions on the subject but I wish to make this an exhaustive index for easy reference.

Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • Somewhat related; my attempt to list fixable bugs by version: (30599) – Mr.Wizard Jun 19 '15 at 21:42
  • 1
    It seems this tutorial has been updated through version 12.1 now. – Greg Hurst Mar 19 '20 at 17:48
  • @ChipHurst Thanks! I am glad; this Q&A should not have been needed, as the developers are in a far better position to write such a thing. Nevertheless please let me know if important points here are missing from the official one. – Mr.Wizard Mar 19 '20 at 18:01

1 Answers1

75

Prelude

The items in this post are not generally regressions; they are simply changes and enhancements that may break code or cause problems in moving from one version to another. The work-arounds are offered as specific solutions to instances of incompatibility, not as recommendations of general practice. For example, Plot Themes are a powerful tool one should learn to use; I discourage disabling this tool by setting $PlotTheme = None unless that is needed for a specific result.


Between Versions 11.3 and 12.0

  • Functions in the built-in "MediaTools`" package allowing fast import of AVI files frame-by-frame were renamed and received usage documentation.

  • Total no longer sums over arbitrary heads by default. Use option AllowedHeads -> Inherited for the old behavior, or AllowedHeads -> All to sum over mixed heads. (Reference)

LibraryLink

  • WolframLibraryVersion bumped to 5 (from 4)

Between Versions 11.2 and 11.3

LibraryLink

  • MSparseArray_getExplicitValues() now returns NULL when called with a non-pattern sparse array that has no explicit values stored. Previously, it would return a valid but empty MTensor. It would only return NULL when called on a pattern array.

Between Versions 11.1 and 11.2

  • Rasterize now returns an Image instead of Graphics by default. Use the second argument to specify what format to return.

  • <-> and TwoWayRule introduction

    <-> was parsed as \[UndirectedEdge], now (11.2+) as \[TwoWayRule]. TwoWayRule is interpreted by Graph functions as UndirectedEdge but that does not solve the problem: 158657

  • LinearAlgebra`MatrixConditionNumber is no longer present in 11.2 and several Q&A depend on it; one can use LinearAlgebra`Private`MatrixConditionNumber instead.

LibraryLink

  • WolframLibraryVersion bumped to 4 (from 3)

Between Versions 11.0 and 11.1

  • Image Arithmetic and statistical operations such as Log, Plus and Mean work directly with Image since then e.g. Image[{{1, 2}, {4, 5}}/10] == Image[{{1, 2}, {4, 5}}]/10 now returns True.

Between Versions 10.4 and 11


Between Versions 10 and 10.1

  • In function definitions default value neen not nesessarily match the pattern anymore.

  • FrameTicks no longer recognizes the syntax {bottom, left, top, right}
    Give specifications in the form {{left, right}, {bottom, top}}
    Or redefine an internal function FrameTicksQ: (82675)

  • MovingMap has seen major revision with incompatible syntax changes. (Reference)
    Use the option Method -> "Legacy" within MovingMap to achieve the old behavior

  • Optional behavior has changed in the case of incongruous head patterns. (Reference)

  • ImageAdd and ImageMultiply now by default always assume alpha channel for non-transparent single-channel images to be equal to 1. In previous versions it was taken to be equal to the color channel. (Reference)


Between Versions 9 and 10

  • Join now allows Join[{A[x]}, {A[x]}, 2]: Silent change (bug?) of Join after v9

  • Slot: in V10 #x and #"x" now parse as Slot["x"] and is interpreted as key name x for use with Association. In prior versions these were parsed as multiplication: #1 * x and #1 * "x".
    Add something to act as a separator or use #1 form: # x, #*x, #1x, (#)x

  • Dispatch expressions are now Atomic and cannot be manipulated with Part or patterns.
    Use Normal to convert a Dispatch table into a Rule list.

  • DateDifference now returns a Quantity expression.
    Use DayCount instead or use QuantityMagnitude to strip the units.
    Alternatively, using SetSystemOptions["DataOptions" -> "ReturnQuantities" -> False] will restore the old DateDifference behavior (see Possible Issues section of the DateDifference documentation).

  • DateRange now returns lists with year, month and day regardless of what the increment is.
    The change and possible workarounds are further discussed here.

  • GeoDistance and GeoDirection now return a Quantity expression.
    Use QuantityMagnitude to strip out the units.
    (This solution applies to any function that now returns a Quantity instead of a value.)

  • Klingon character support has been removed. \[KlingonA] etc. are no longer recognized as valid input syntax. Solution unknown.

  • LogPlot and family no longer provide standard log plot gridlines when Automatic is specified.
    A GridLines function based on the internal Ticks generator may be used. (broken in 10.0.0)

  • PlotTheme changes the fundamental style of most plots and overrides BaseStyle and GraphicsBoxOptions settings.
    Use PlotTheme -> None, individually or with SetOptions or $PlotTheme.

  • PlotLegends -> "Expressions" does not generate a legend when used with a single plot function.
    Use PlotLegends -> "AllExpressions" instead.

  • PlotLegends now does not automatically generate more legend items than there are colors in the working color scheme. (Reference)
    Use a color scheme with a sufficient number of colors to differentiate all plot elements, a gradient scheme, or a manual legend specification.

  • ParallelNeeds defaults to the System context when loading packages which introduce symbols outside the package context. In previous versions (and Needs) these symbols are in the Global context. This has been confirmed by Wolfram support as a design decision, not a bug.
    Create global symbols within package files in the Global context explicitly, as in Global`x.

  • NSolve returns the same solution several times to indicate its multiplicity. Before V10 it returned a solution with multiplicity only once. (Reference)
    Use DeleteDuplicates@NSolve[...]

  • Nearest gives message and returns unevaluated when given an empty list as first argument. In Version 9 and before an empty list was returned.
    check for empty lists before calling Nearest or for unevaluated Nearest in result...

  • WeatherData now returns a TemporalData object using TimeSeries and Quantity rather than a plain array.
    Use Normal and QuantityMagnitude to recover the plain form for legacy code.

  • ListPlot and ListLinePlot may use a wider Automatic plot range than expected when working with data that covers a very small range. (Reference)
    Use the undocumented option "AllowMicroRanges" -> True for individual plots or set SetOptions[System`ProtoPlotDump`iListPlot, "AllowMicroRanges" -> True].

  • Blur, ImageConvolve, GaussianFilter now aren't applied to the alpha channel of Image (what is consistent with behavior of ImageAdjust, Dilation etc.). ImageFilter and ImageCorrelate still affect the alpha channel.
    To reproduce the old behavior one should remove the colorspace information.

  • ImageCompose has lost the associative property and produces entirely different results than earlier. The solution is to divide the color channel of the output by its alpha channel.


Between Versions 8 and 9

  • Image expressions are now Atomic; data cannot be extracted using Part.
    Use ImageData and Options to extract raster data and options respectively.
    Use PixelValue or ImageValue to query raster values
    Replacement rules are overloaded to work: Image[{{.1, .3, .9}}] /. _[x__] :> {x}

  • Interpolation of an unstructured grid is in V8 possible for more than 3 dimensions (linear interpolation only). In V9 and higher Interpolation in more than 3 dimensions is not possible. (Reference)
    3rd party realizations of unstructured grid interpolations are available here, here, here, and here ( using different approaches and with different performance).

  • TeXForm no longer works properly with Row expressions, whether by design or oversight. (Reference)
    Set BoxForm`$UseTemplateSlotSequenceForRow = False;

  • Solve can now return ConditionalExpression objects, rather then just one particular branch of the inverse.
    Use Normal to remove the ConditionalExpression head. This however does not remove any GeneratedParameters.
    Revert to version 8 behavior via SystemOptions: SetSystemOptions["ReduceOptions" -> "UseTranscendentalSolve" -> False].

  • General Legend functionality has been overhauled. Many things do not work quite the same and many low-level methods no longer work. (Example)

  • PlotJoined option for ListPlot is no longer accepted. (It was deprecated in 6.0 but continued to work.)
    Use Joined in its place, or ListLinePlot.


Between Versions 7 and 8

  • Hash now gives the hash of a raw sequence of characters when applied to Strings. In past versions the string characters (quotation marks) were included in the calculation of the hash. (Reference)
    Use "\"" <> string <> "\"" before hashing if you want output to match older versions.

  • \[Dash], \[LongDash] and \[Hyphen] may no longer be used as part of Symbol names. (Reference)

  • ImageCrop no longer removes layers of bordering pixels with color values that exactly match the colors of the borders, now it "removes borders from image whose pixel value distribution is almost uniform."
    A workaround is to use ImagePad[img, -BorderDimensions[img, 0]] instead of ImageCrop.



Non-version-specific

  • Hash used without a specified type cannot be expected to return the same value from one version or platform to the next. There appears to be no way to compute the Hash values from older versions apart from actually running that version of Mathematica.
    Specify a hash type if you intend to rely on the stability of these values.
Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • 15
    Klingon character support has been removed: that's because Klingons do not respect the Galactic Copyright Treaty – magma Aug 06 '14 at 09:29
  • 4
    Writing #x and #"string" in versions < 10 to mean # x and # "string" respectively is bad form anyway (a habit propagated by the Church of the Tersists, no doubt ;)). Such code deserves to be broken :P – rm -rf Aug 06 '14 at 16:18
  • 1
    @rm-rf The interactive editor would previously auto-space such things just as it still does when you type 3x. (I don't mean that it enters a literal space but rather shows the expression with spacing.) Do you always type a space between such things? I have not as it seemed like wasted effort. – Mr.Wizard Aug 06 '14 at 16:27
  • Yup, I almost always write a space for implicit Times. Probably started doing that because I used to (and still do) write in code cells or with non-interactive editors such as vim/IDEA. – rm -rf Aug 06 '14 at 16:58
  • @rm-rf Regarding your changing this post to CW, I suppose that is appropriate if this is to be the sole answer, but I actually did not intend that, though I failed to state my intentions in the Question. I chose an Issue: Solution: format unlike the existing documentation, which is simply a bulleted list of changes with no comment on impact or work-arounds. I thought others might have a different idea for how this information should be presented. Do you feel that the format I chose is sufficiently universal to be the sole answer? – Mr.Wizard Aug 06 '14 at 17:46
  • @Mr.Wizard I think we have (at least in the past) consistently been applying CW to anything that calls for a growing and collaborative "list of x" regardless of whether that list is presented as one post or many. It is a more recent phenomenon that such questions are not CW, but that seems more an oversight... I don't have a particular opinion on the format — I'm sure there are other equally useful formats that others might come up with. Your choice shouldn't prevent them from using theirs. I added my entry to yours in your format because I didn't think it warranted a new post. – rm -rf Aug 06 '14 at 18:24
  • @ Mr. Wizard - You might consider rcollyer's excellent answer to this question: http://mathematica.stackexchange.com/questions/56829/plotlegends-expressions-not-working-when-plot-given-one-function – eldo Aug 08 '14 at 00:00
  • @eldo Thanks; added. – Mr.Wizard Aug 09 '14 at 18:05
  • I can't edit Mr. Wizard's answer, so he is welcome to add this to his list at his discretion.

    In version 9, expressions evaluated in parallel default to the Global context. In version 10, expressions evaluated in parallel default to System. This causes shadowing when using ParallelNeeds on packages which are supposed to define global symbols, and leaks symbols into the System context.

    This has been confirmed by Wolfram support as a design decision, not a bug.

    – Daniel W Aug 09 '14 at 19:40
  • @Daniel This is a Community Wiki answer and it should only take 100 "reputation" to edit it. Did you try? And thanks for reporting this change. – Mr.Wizard Aug 09 '14 at 19:59
  • @Mr.Wizard Thanks for letting me know. I was not aware of circumstances where I could edit someone else's post. Also, it seemed presumptuous for me to edit your post. Should I just copy/paste the comment into the post as it is? – Daniel W Aug 10 '14 at 14:34
  • @Daniel The edit looks good. Thanks! – Mr.Wizard Aug 10 '14 at 17:24
  • 1
    @eldo, I think the Inset thing is a bug rather than a deliberate change, so it doesn't belong in this list in my opinion. – Simon Woods Aug 12 '14 at 21:08
  • @SimonWoods I agree, thanks and deleted :) – eldo Aug 12 '14 at 21:11
  • @DanielW Do you have a link to a discussion about this? – Szabolcs Aug 16 '14 at 16:32
  • 1
    @Szabolcs The original report was filed online, I did not keep a copy. Below is a copy of the reply from support:

    Thanks for contacting Wolfram Technical Support. Regarding the issue you reported, it seems this is an intentional design change. We have internal discussions on this and the argument from the developer is that "Setting $Context to $System on subkernels is necessary to make sure (new) system symbols arrive in the correct context on subkernels, because despite the MathLinkPrintFullSymbolName settings, system symbols do not have their context attached".

    – Daniel W Aug 20 '14 at 00:52
  • Is it worth mentioning that the InterpolationFunction compatibility issue has been fixed in v10.0.1 ? – RunnyKine Sep 20 '14 at 12:50
  • @RunnyKine To begin with you should post that here: (57608) Probably that item can be removed from this list as this post is not intended to catalog corrected bugs. – Mr.Wizard Sep 20 '14 at 13:29
  • Could you elaborate on what is the difference with Hash in version 10? The documentation doesn't seem to show any important differences, but since I'm using Windows 2003 I don't have version 10 on this computer to verify it. – Oleksandr R. Jan 14 '15 at 01:56
  • @Oleksandr Simply: the (default) hash value returned for a given expression in v10 does not match the (default) hash value from earlier versions. – Mr.Wizard Jan 14 '15 at 02:57
  • Versions 7 and 8 give the same hash value, but in general, the other versions don't. I couldn't see any big differences in the overall magnitude or distribution of the values between 9 and 10, so I would say the algorithm is probably the same, but some internal detail has changed that leads to slightly different results. In general I think the constancy of hash values between versions is something we shouldn't rely on. The only important thing is that there should be no collisions. – Oleksandr R. Jan 14 '15 at 10:06
  • @Oleksandr Interesting. Do you know if all pre-version-8 Hash values were the same? At this point it's clear we shouldn't rely on a constant (default) hash value, but it may have seemed like a reasonable expectation at some time in the past. – Mr.Wizard Jan 14 '15 at 10:21
  • Version 8 and 9 differ; version 5.2 also differs from version 7. I don't have version 6 installed any more so I can't check that, but I wouldn't be surprised if it differs as well. The 32- and 64-bit kernels give the same value as each other in versions 7 and 8, but not in version 9. The magnitudes of the hashes in the 32- and 64-bit kernels of version 9 are also rather different (basically, the 64-bit version gives a 62-bit hash, but the 32-bit one gives 31 bits). – Oleksandr R. Jan 14 '15 at 10:34
  • @Oleksandr Thanks. I wasn't the one who added that item to this list so I hesitate to remove it entirely, but I think it needs to be amended with this information. – Mr.Wizard Jan 14 '15 at 10:34
  • Countries in CountryData[] in Mathematica 10.1 are represented as an Entity while in versions 9.0 (and presumably earlier) they are not. – David G. Stork May 20 '15 at 16:05
  • "returns the same solution several times to indicate its multiplicity" - I'd argue that this is actually an improvement. – J. M.'s missing motivation Jul 09 '15 at 17:47
  • @Guess Is there something in this post that seems to indicate otherwise? – Mr.Wizard Jul 09 '15 at 17:49
  • Well, the suggestion of using DeleteDuplicates[] looks like throwing away useful information to me here, you see. – J. M.'s missing motivation Jul 09 '15 at 17:51
  • @Guess Ah, I think I understand the confusion. The bulleted points are not meant as (general) suggestions but specific backward-compatibility patches. The items in this answer are not to be seen as backslides or bugs; they are simply changes that may result in old code (or methods) not working as anticipated, and quick fixes when known. Maybe something about this should be included in a Prelude section? – Mr.Wizard Jul 09 '15 at 17:54
  • Ah, that's cool then. You can add a prelude, of course. – J. M.'s missing motivation Jul 09 '15 at 17:57
  • @Guess Please let me know if that is sufficiently clear and concise. – Mr.Wizard Jul 09 '15 at 18:07
  • Yes, it's now good. :) – J. M.'s missing motivation Jul 09 '15 at 18:09
  • @Mr.Wizard was adding one example and ended up reversing the order :), I think it is more user friendly. Also, I've changed layout a little, let me know what do you think, but I can read when headers have the same indentation as items inside. – Kuba May 24 '17 at 21:59
  • @Kuba I was following the order of the existing official documentation, but I don't have a strong opinion about it either way. I suppose your order puts the information most people will be most interested in at the top. The formatting looks good. Thanks. – Mr.Wizard May 25 '17 at 00:12
  • @Szabolcs I have version 10.0.1 installed on my machine (Win7 x64) and with it img = Import["http://i.stack.imgur.com/UsJTa.png"]; ImageData[Blur[img, 5]] == ImageData[img] returns True. That's why I'm sure that the change was introduced in 10.0. Do you get other result with version 10.0? – Alexey Popkov Sep 21 '17 at 09:54
  • @AlexeyPopkov hm... sorry for sticking my foot in this. I was just trying to be helpful; I didn't realize it was contested. (I get True in 10.1.0 under Windows x64, for what it's worth.) – Mr.Wizard Sep 21 '17 at 09:59
  • @AlexeyPopkov You are right. There's something weird: copy-pasting an image from 10.4+ to 10.3- loses (actually: flattens) the alpha channel. Copy-pasting an image from 10.3- to any 10.0+ version does retain the alpha channel. (This is at least what happens on OS X.) – Szabolcs Sep 21 '17 at 10:10
  • @Szabolcs I also faced this: copying the image from version 11.2.0 and pasting into versions 8.0.4, 9.0.1 and 10.0.1 results in transparency being flattened, but with version 10.4.1 its OK. That's why I rely only on Import for testing and also check the result with ColorSeparate. – Alexey Popkov Sep 21 '17 at 10:18
  • @MichaelE2 Please add it. At the present time this list is a manageable size and I believe it is better to tend toward exhaustiveness. If at some point it becomes unmanageable it may be better to remove such things to a separate post. – Mr.Wizard Aug 01 '18 at 19:58
  • I think LinearAlgebra`MatrixConditionNumber changed in between 11.1 and 11.2. – Greg Hurst Aug 02 '18 at 03:25
  • Thanks @Chip I have only 11.3 now and didn't notice before. – Michael E2 Aug 03 '18 at 17:10
  • @johu The description "$MachinePrecision is the new default" is incorrect. Aside from those I've added in the community wiki, notice $MachinePrecision and $MachinePrecision are different, check this post for more information. – xzczd Sep 23 '18 at 11:12
  • @xzczd Thanks! I admit I still to do not understand the fully story, but thought that even incomplete hint to the problem is better than none. I have struggled a lot getting my old code back the stability and performance. Note the typo in your comment... I guess you wanted to say: MachinePrecision and $MachinePrecision are different. – Johu Sep 23 '18 at 11:22
  • @Johu Oops… Yes, I mean $MachinePrecision and MachinePrecision are different. – xzczd Sep 23 '18 at 11:28