Skip to main content
19 events
when toggle format what by license comment
Apr 17, 2015 at 17:01 comment added Mr.Wizard @Oleksandr Good point. I was only going off Tali's "I've filed a bug for this" but perhaps it is more of a limitation than a bug?
Apr 17, 2015 at 10:20 comment added Oleksandr R. Just a small comment on an old question. Since packed arrays were only introduced in version 5.0, I would think that if it exists in 5.2 it probably was a simple omission in the (AIUI, involved) operation of grafting packed arrays into the language in the first place. I am not quite sure what this meant about its "bug-ness" before the report was filed.
Apr 15, 2015 at 22:30 history edited Mr.Wizard CC BY-SA 3.0
added 76 characters in body
Feb 10, 2015 at 6:50 vote accept Mr.Wizard
Feb 10, 2015 at 6:50 history edited Mr.Wizard
edited tags
Feb 9, 2015 at 18:42 answer added Taliesin Beynon timeline score: 7
Aug 3, 2014 at 9:47 comment added Leonid Shifrin @Mr.Wizard Well, I think this was kind of easy to guess, since the pattern matcher has no way to not unpack for this particular rule.
Aug 3, 2014 at 4:42 comment added Mr.Wizard @Leonid I see from these comments that a year ago I was unaware that this also unpacks one level: /. h_@x__ :> h@x
Jul 24, 2013 at 14:22 comment added Leonid Shifrin @Mr.Wizard Map only unpacked because the length of the list was smaller than "MapCompileLength" setting. And Outer is rather inelegant, I agree.
Jul 24, 2013 at 14:01 comment added Mr.Wizard @Leonid I believe you could also use #& /@ packed, and even other functions such as Outer, though inelegantly: Outer[# &, packed, {1}, 1][[All, 1]]
Jul 23, 2013 at 9:10 comment added Leonid Shifrin @MichaelE2 I would agree that the special case of List was probably considered not important. In fact, the only reason one would want to do List @@ packed would be if one wants to unpack one level. It also seems to be the only way to do this (i.e. using Apply), if one wants to only unpack one level.
Jul 23, 2013 at 3:49 comment added Michael E2 I had thought @m_goldberg's question was why is Apply designed that way. That Apply always unpacks the first level is not an explanation why it does it when it's unnecessary. I would think that it's because List @@ List[..] is not important enough to make a special case. Or it's so that {a, b, c} = List @@ tensor is a workaround for Set's behavior. Or something else like that.
Jul 23, 2013 at 3:22 history edited Mr.Wizard CC BY-SA 3.0
added 119 characters in body
Jul 23, 2013 at 3:19 comment added Mr.Wizard @m_goldberg Yes, that is what I tried to express that with the final example given. Another way to look at this problem is that apparently when Set gets a packed array on the RHS and a list on the LHS, it fully unpacks the RHS rather that only unpacking it to the level of the LHS. This seems like an unfortunate choice, but I have often learned that there are good reasons for such choices once I asked about them.
Jul 23, 2013 at 2:16 comment added m_goldberg @LeonidShifrin. So, although it's not his main point, one thing Mr.Wizard is telling us is that when Set is given tensor with its top-level unpacked, the lower levels will not be disturbed.
Jul 22, 2013 at 22:59 comment added Leonid Shifrin @m_goldberg Because Apply does unpack the top level of the packed array. It does it always, even if the head to be applied is also a List.
Jul 22, 2013 at 19:58 comment added m_goldberg Your question raises another in my mind: since tensor already has the head List, why does List @@ tensor have any effect on Set at all, considering it's evaluated before Set even sees it?
Jul 22, 2013 at 14:35 history tweeted twitter.com/#!/StackMma/status/359320701003513857
Jul 22, 2013 at 14:16 history asked Mr.Wizard CC BY-SA 3.0