Christian: You are right, it would not be best to confuse normal perl
lists with compact arrays--they both have their purposes and can be
combined usefully.
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo -- array
%foo -- hash
^foo -- compact array (or whatever notation)
Given this notation, you could have hashes of compact arrays, lists of
compact arrays, etc. There are still sticky questions about how much
should be done in the perl core and how much in modules. It would, of
course, make no sense to hack deeply into the perl core to add a new
fundamental type if everything useful that could be done with that type
required a separate module...
Just my $0.02
Doug
Christian Soeller wrote:
>
> Doug Hunt wrote:
>
> > But I would like to speak up in support of Baris' idea. I have long
> > found it
> > confusing (both to myself and to those I must explain my code to) the
> > mix of
> > pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
> > appear to be scalars. I was even asked once why some arrays look like
> > arrays and other look like scalars.
> >
> > It seems to me that scalars are quite overloaded these days. I suppose
> > the question is:
> >
> > Do we want to continue the perl4 tradition of syntactic markers for
> > different data types, or do we want to lump everything together?
> >
> > Since I'm in the 'numeric' camp, I would vote for full membership of the
> > compact array type in the set of perl types.
>
> I am not sure that PDL objects (piddles) are actually best represented
> by arrays. It is much better to think of what are now piddles as a
> rectangular region of nD space. The array '@' signals array context and
> we don't want every function that returns a piddle to signal array
> context. We now have functions that return lists of piddles
>
> ($fit,$fwhm) = fitgaussian $x, $y
>
> and the distinction between list context and scalar context is a good
> one to have with piddles as well.
>
> The other problem with arrays is: how do we deal with functions that
> take multiple piddle arguments if they are arrays:
>
> @result = integrate @x, @y, @bounds;
>
> Won't those all be clumped into one big input array? Does it mean we
> have to write
>
> @result = integrate \@x, \@y, \@bounds;
>
> which seems bad to me.
>
> Secondly I feel that the history of array indexing stands in the way of
> the flexibility that piddle-like things need. So we are probably better
> off asking for a
>
> $pdl(0:-1,:2)
>
> syntax for slicing. That leaves request for a default method and ';' as
> range operator.
>
> Christian
--
[EMAIL PROTECTED]
Software Engineer III
UCAR - COSMIC
Tel. (303) 497-2611
