2
$\begingroup$

Below is an illustration of the problem.

 a={1->{{8,9},{8,22}},2->{{8,3,19},{8,14,19}}};
 b={1->{1,2},2->{1,2,3}};
 Manipulate[
 Manipulate[
  Thread[case->(item/. b)],
  {case,item/.a,ControlType->Setter}],
 {item,Keys@a}]

If you run the above code, it will show this

enter image description here

then if you switch to item 2, you got an Thread error like this

enter image description here

The error says, Thread encounters unequal length objects. However, the output of Manipulate is actually right! I don't get it, why there is an intermediate error? How to get rid of this error?

Improve this question
$\endgroup$
2
  • $\begingroup$ Since the output is okay, you could use Off[Thread::tdlen] as a very, very nasty hack. Lateron, you can reactive these error messages with On[Thread::tdlen]... $\endgroup$
    – Henrik Schumacher
    Commented Feb 24, 2018 at 11:09
  • $\begingroup$ @HenrikSchumacher Thanks! Indeed, I can also mask it with Quiet. But wait for an explanation and a formal way to get rid of it : ) $\endgroup$
    – matheorem
    Commented Feb 24, 2018 at 11:39

1 Answer 1

Reset to default
2
$\begingroup$

It seems to be a question of timing. The code segment Thread[case -> (item /. b)] is being updated before the inside Manipulate. This can happen, I suppose, because the Thread[..] segment is wrapped in Dynamic[] and is dependent on the symbols {case, item, a, b}. When Thread[..] is updated, item has changed, but case has not yet been updated. This causes the mismatch in lengths.

The fix would be to control the dependencies with TrackedSymbols and/or Dynamic/Refresh. Both of the following eliminate the problem (adjust to suit desired dependencies):

Manipulate[
 Manipulate[
  Thread[case -> (item /. b)],
  {case, item /. a, ControlType -> Setter},
  TrackedSymbols :> True],
 {item, Keys@a}]

Manipulate[
 Dynamic@Refresh[
   Manipulate[
    Thread[case -> (item /. b)],
    {case, item /. a, ControlType -> Setter}],
   TrackedSymbols :> {item}],
 {item, Keys@a}]

In my opinion I can how this could be considered a bug. When you have nested dependencies that all require an update, do you update from the bottom up or from the top down? In this simple example, the top-down approach should be down.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Hi, Michael E2. Thank you very much! +1 for solving the issue. But I don't quite understand TrackedSymbols. For example, in the first example, TrackedSymbols :> Manipulate, what does this Manipulate refer to? The outer manipulate or inner manipulate? And I don't understand why Manipulate can track itself? $\endgroup$
    – matheorem
    Commented Feb 24, 2018 at 15:16
  • $\begingroup$ @matheorem TrackedSymbols :> Manipulate apparently is now supposed to be TrackedSymbols :> True: Both track the symbols in the controls in the Manipulate, so they would be the same as TrackedSymbols :> {case} in example. I learned the first one in a class when V6 came out. $\endgroup$
    – Michael E2
    Commented Feb 24, 2018 at 15:30
  • $\begingroup$ Thank you so much $\endgroup$
    – matheorem
    Commented Feb 25, 2018 at 1:20

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.