develooper Front page | perl.perl6.internals | Postings from September 2002

RE: [netlabs #801] [PATCH] PerlArray in scalar context

Thread Previous | Thread Next
From:
Sean O'Rourke
Date:
September 5, 2002 07:25
Subject:
RE: [netlabs #801] [PATCH] PerlArray in scalar context
Message ID:
Pine.GSO.4.32.0209050715390.11815-100000@gradlab.ucsd.edu
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,

/s


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About