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$
5
  • $\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, 2015 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, 2015 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, 2015 at 13:44
  • 2
    $\begingroup$ PrintDefinitions and other techniques reveal that this is an issue of TemporalData`Utilities`TDRollingMap $\endgroup$ Nov 18, 2015 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$ Nov 18, 2015 at 15:31

1 Answer 1

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$
0

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.