The MovingMap window spec has been changed between version 10.1 and 10.0.2.

Version 10.0.2

MovingMap[h, {a, b, c, d, e, f}, 2]
(* {h[{a, b}], h[{b, c}], h[{c, d}], h[{d, e}], h[{e, f}]} *)

Here we get a moving window of 2 items as expected.

Version 10.1

MovingMap[h, {a, b, c, d, e, f}, 2]
(* {h[{a, b, c}], h[{b, c, d}], h[{c, d, e}], h[{d, e, f}]} *)

In 10.1 the same statement returns a moving window of 3 items.

Is there a way to have a bug marked as urgent. I have a few functions in a package that I made in 10.0.2 that I am using in 10.1 that use MovingMap and direct uses scattered about in notebooks.

I think all the other "moving" functions should be testing as well.

Update on outcome

The short story is that the change was accidentally omitted from 10.1 release notes which lead to it being interpreted as a bug (it is a breaking change but not a bug). Below in there is a response (unofficial) in one of the comments from a WRI employee that states WRI is looking into how this happened in order to prevent this in future. And the beat goes on.

enter image description here

  • 3
    $\begingroup$ There is no meaning on SE of marking a bug as "Urgent", this isn't a formal support forum for Mathematica. Bug logging/remediation requests need to be made directly to Wolfram. You might want to rephrase your question to a request for a workaround. $\endgroup$ Commented Apr 15, 2015 at 10:32
  • $\begingroup$ Yes, I just copied my text to support and formatted it for SE. Should have removed that bit. $\endgroup$
    – Edmund
    Commented Apr 15, 2015 at 10:33
  • $\begingroup$ I added ss with docs. I have no idea what to think about 10.1 page. Details about windowsize are only describing usage for timeseries. $\endgroup$
    – Kuba
    Commented Apr 15, 2015 at 10:42
  • $\begingroup$ Haven't had time to explore fully but the fact that Quantity seems to act as workaround seems to suggest that a plain "2" is being interpreted as something other than a plain integer. The help mentions Day a lot. $\endgroup$ Commented Apr 15, 2015 at 10:54
  • 1
    $\begingroup$ No matter how ridiculous the behavior appears it is best to not start with the bugs tag applied as this is conventionally applied after an issue has either been confirmed by WRI as a bug or there is at least community consensus. $\endgroup$
    – Mr.Wizard
    Commented Apr 15, 2015 at 16:35

3 Answers 3


This is not a bug. MovingMap underwent a significant design change in 10.1. Please consult the documentation for details on the new specification. For your particular example, you would now do

MovingMap[h, {a, b, c, d, e, f}, Quantity[2,"Events"]]
  • 2
    $\begingroup$ Any other already documented functions underwent similar procedure?... $\endgroup$
    – Kuba
    Commented Apr 15, 2015 at 23:02
  • 10
    $\begingroup$ @StefanR It is a severely poor practice to change the functionality of a feature and make no explicit mention of it to users. MovingMap has been developed into solutions with the existing 10.0.x functionality. WRI deliberately changing it without notice introduces significant logical errors into existing code. Errors that the developer has no reasonable means to identity or narrow as zero information has been provided. I strongly urge WRI to explicitly state what functions have been altered such that legal syntax produces different results. How is anyone to manage without this info? $\endgroup$
    – Edmund
    Commented Apr 15, 2015 at 23:41
  • 2
    $\begingroup$ I thought I might have missed something so double-checked Summary of New Features in 10.1. As I remembered, no mention of changes to MovingMap. This just can't be done! You can't have changes in results for the same parameters on what should be deterministic functions and leave it to pure chance that the developers using your product will find them. It is ludicrous! I'm thinking: What else has changed in this manner? What other production code is broken from something like this? $\endgroup$
    – Edmund
    Commented Apr 15, 2015 at 23:46
  • 4
    $\begingroup$ Apologies for what may seem like a flippant comment, but what is the value of having a quantity required in the third place? Nowhere else in Mathematica do we refer to raw numbers having units. And what would be the meaning of, for example, MovingMap[..., Quantity[2, "Kilograms"]]? $\endgroup$ Commented Apr 16, 2015 at 10:07
  • 3
    $\begingroup$ @Edmund It should definitely have been mentioned in the release notes. We are looking into why it wasn't included, and how we can avoid such omissions in the future. We are sorry for any frustration due to this issue. This was the only major backwards-incompatible redesign in 10.1 in statistics, and I'm not personally aware of other WL functions that were similarly extensively changed. $\endgroup$
    – Stefan R
    Commented Apr 16, 2015 at 18:25

MovingMap as of 10.1 specifies windows by their absolute length. Since lists are treated as implicit time-series with (zero-based) integer index as time, window size of 2 means that the windowing function sees $\{x_{n-2}, x_{n-1}, x_n\}$. This is the only window specification that admits a clean generalization to irregular time series.

Using Quantity[2,"Events"] specifies possibly variable size window that always includes 2 events (points).

In[26]:= tvPairs = 
 Table[{t, x[t]}, {t, Accumulate[PadLeft[{}, 6, {1, 3}]]}]

Out[26]= {{1, x[1]}, {4, x[4]}, {5, x[5]}, {8, x[8]}, {9, x[9]}, {12, 

In[27]:= MovingMap[f, tvPairs, 2]

Out[27]= {{4, f[{x[4]}]}, {5, f[{x[4], x[5]}]}, {8, f[{x[8]}]}, {9, 
  f[{x[8], x[9]}]}, {12, f[{x[12]}]}}

In[28]:= MovingMap[f, tvPairs, Quantity[2, "Events"]]

Out[28]= {{4, f[{x[1], x[4]}]}, {5, f[{x[4], x[5]}]}, {8, 
  f[{x[5], x[8]}]}, {9, f[{x[8], x[9]}]}, {12, f[{x[9], x[12]}]}}


The legacy behavior, can also be recovered using Method->"Legacy" option.

In[29]:= MovingMap[f, tvPairs, 2, Method -> "Legacy"]

Out[29]= {{4, f[{x[1], x[4]}]}, {5, f[{x[4], x[5]}]}, {8, 
  f[{x[5], x[8]}]}, {9, f[{x[8], x[9]}]}, {12, f[{x[9], x[12]}]}}


Notice that MovingMap has become much more powerful in 10.1. It is now possible to align windows at specific positions. For instance, consider a daily closing values of the Starbucks stocks from the beginning of 2002 and through the end of 2014.

sb = TimeSeries[FinancialData["SBUX", {{2002}, {2014}}]];

The following computes past monthly median weekly starting from Fri, Feb 1 of 2012:

MovingMap[Median, sb, {"Month", 
  Right, {"Feb 1 2002", Automatic, "Week"}}, None]

This was not easy to do in v9.

enter image description here


I would echo's @Kuba comments about most of the examples being for Time related windows, I would also note that there is an explicit example in the help that returns a window size of 3, so it could be an indication that its deliberate.

MovingMap[Mean, {x1, x2, x3, x4, x5}, 2]

(* {1/3 (x1 + x2 + x3), 1/3 (x2 + x3 + x4), 1/3 (x3 + x4 + x5)} *)

There is a workaround that seems to have no ill effects though.

MovingMap[h, {a, b, c, d, e, f}, Quantity[2, "Events"]]

(* {h[{a, b}], h[{b, c}], h[{c, d}], h[{d, e}], h[{e, f}]} *)
  • $\begingroup$ I also had a quick play with the Window Alignment options (Left, Center, Right) but they did nothing. Maybe the key is differentiation of Discrete and Continuous data? $\endgroup$ Commented Apr 15, 2015 at 10:56
  • 3
    $\begingroup$ O nooo!!.. MMA is starting counting from 0!.. :) so 1 -> 0 and 1, 2 -> 0,1,2 $\endgroup$
    – Murta
    Commented Apr 15, 2015 at 13:25
  • $\begingroup$ @Murta Try with 1.9 :P $\endgroup$
    – Kuba
    Commented Apr 15, 2015 at 13:32

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.