9
$\begingroup$

I don't why this happens, I don't know if those two examples are related.

I don't have time to investigate, but maybe someone can solve this?

MovingMap[Apply[RandomReal], Range[5], 1]
MovingMap[Apply[RandomReal], {1, 2, 3, 4, 5}, 1]

TemporalData::dmnsns: The dimensionality implied by the states in {{{0.8754,0.581},{1.10292,<<19>>,1.3597},{<<1>>},{1.19292,1.14424,0.278258,3.10511,1.18676}}} is mixed. A single-state dimensionality is expected. >>

and:

MovingMap[Apply[Rule], Range[5], 1]
MovingMap[Apply[Rule], {1, 2, 3, 4, 5}, 1]

I don't need workarounds since they are basic.

Win7, V10.2, V10.3

$\endgroup$
  • $\begingroup$ If someone is interested, please send a bug report, something is wrong with my license or with me but I'm not getting anything back from them lately. $\endgroup$ – Kuba Nov 18 '15 at 13:02
  • 1
    $\begingroup$ V.10.0.0.0 -- First example: Can't repro; second -- Rule::argr: Rule called with 1 argument; 2 arguments are expected. $\endgroup$ – Sektor Nov 18 '15 at 13:40
  • 1
    $\begingroup$ I confirm, 10.3 on Linux. Something wrong in the output stage of MovingMap. I see echo from Apply[Rule]@*Echo and the correct output from List@*Apply[Rule]. $\endgroup$ – ybeltukov Nov 18 '15 at 13:44
  • 2
    $\begingroup$ PrintDefinitions and other techniques reveal that this is an issue of TemporalData`Utilities`TDRollingMap $\endgroup$ – Jacob Akkerboom Nov 18 '15 at 15:27
  • 2
    $\begingroup$ Also note that with a fresh kernel, Quiet[MovingMap[Apply[RandomReal], Range[5], 1]] still issues a message, which I guess is a bug of Quiet. $\endgroup$ – Jacob Akkerboom Nov 18 '15 at 15:31
7
$\begingroup$

This is a limitation in TemporalData that MovingMap was designed to work with. Note that TimeSeries and EventSeries are really just special cases. I don't know if it is a necessary limitation but a decision was made at the time they were created that the dimensionality of the data values need to be consistent.

Now whether this restriction should be relaxed and whether it should operate differently on lists is certainly a valid question. I also think it should be a little smarter about what message it issues and the documentation should be more clear about this limitation.

All that said, since it was a deliberate design decision, I don't think WRI will consider this a bug in the functionality but a bad message and incomplete documentation.

EDIT

Now when it comes to why Rule behaves differently. Under the hood everything gets packaged up in TemporalData and is checked for consistency using TemporalData's internal validation functions. But TemporalData seems to have special handling for a list of Rule, presumably allowing for a specification {time1 -> value1, time2 -> value2, ...}. An undocumented feature? In any case, this is surprising and shouldn't occur when MovingMap is given a list since the user has no reason to expect that this has anything to do with TemporalData.

In[87]:= TemporalData[{1 -> 2, 3 -> 4, 5 -> 6, 7 -> 8}]["Path"]

Out[87]= {{1, 2}, {3, 4}, {5, 6}, {7, 8}}

In[88]:= TemporalData[{h[1, 2], h[3, 4], h[5, 6], h[7, 8]}]["Path"]

Out[88]= {{0, h[1, 2]}, {1, h[3, 4]}, {2, h[5, 6]}, {3, h[7, 8]}}
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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