On Thu, 5 Sep 2002, Brent Dax wrote: > Sean O'Rourke: > # > # 4 - the other arrays boosted to the highest dimension > # > It's already been defined to be #4. > # > # Argh. Then I need to whinge a bit -- what if it's a ragged > # array? What if different elements have different dimensions > # themselves, e.g. "[1,[2,3]]"? I think there's serious > # can-of-worms potential here, and by making hyping more > # "intelligent", we'll actually make it useful in fewer cases. > > I don't see any cases where it becomes *less* useful by making it more > intelligent. Can you give an example? I was thinking of something like this: my (@xs, @ys) = two_arrays_of_arrays; my @zs = @as ^dot_product @bs; > As for the ragged array argument, I would argue for the following > statement in the documentation: > > The behavior of hyperoperators with ragged and recursive > data structures is undefined (and likely to be downright > weird). But we can do better than this if we (a) say that hyping only goes down one level by default; and (b) reduce hyping (without complaint) to a scalar operation when both operands are scalars. > Absolutely. If we know the dimensions at compile-time, we should use > that information. But I have a sneaking suspicion that that won't be > the general case. D'oh. I meant 'number of dimensions' rather than dimensions. Your statement above seems right if and only if hyping applies to all dimensions by default. > c) possibly speed up execution (optimizer gooooood...) We already get some benefit here. For more, you're likely to implement a bona fide matrix or vector PMC, for which the normal operators will do "hyper" things. > # That would be pretty hard (I think), since it involves > # coalescing two subs into one, then cleaning out a bunch of > # temporaries. > > Perhaps. Looking for identical subs seems like an obvious size > optimization to me, but I'm not really a compiler guy. :^) You could be, any day you chose ;). At least as much as yours truly, /sThread Previous | Thread Next