> "David L. Nicol" wrote:
> >
> > These things sound like perfectly reasonable CPAN modules.
> > What's the block prevenenting their implementation w/in the
> > perl5 framework?
>
> Jeremy and I are working on a general purpose matrix/unmatrix function
> that may well be core-worthy. This would allow arbitrary reshaping of 2d
> (Nd?) arrays into any form imaginable.
>
> However, I would probably argue that zip/unzip/merge/unmerge/whatever go
> into a module (Math::Matrix?) since they'll probably just be specialized
> calling forms of matrix/unmatrix. I think the trend is to put a lot of
> formerly-core functions and features in modules, especially if subs get
> fast enough (and it sounds like they're going to).
>
]- One possible implementation of MATRICES is for example :
As I read in perlguts-illustrated the array is represented as a array of
POINTERS i.e.
(pointer to $a[0], pto $a[1], pto $a[3]...., pto $a[n])
then we can have f.e. "matrix" :
matrix 10x5, @a;
this just reorders the list in the following LIST-ARRAY structure :
(pto $a[0] .. $a[9]) --next-> (pto $a[10] .. $a[19]) ---next-> (....)
now we have chained-arrays. The benefit :
(@a is now internally known for perl as MATRIX)
push @a,@b;
will push one by one all elements of @b into correspondending rows in @a
matrix .... push is now executed in MATRIX CONTEXT.
If you gotcha the idea then all splice, pop,shift, unshift will do their
correspodending roles. (offcource there is some glitches such as what happen
if the @b array is smaller/bigger the necessary elements for the matrix -
then we can have fillwith zeros, with default value ... etc)
THE other operator "unmatrix" just convert the matrix back to array..
We can easly access say element 250 for example like $a[250] 'cause the
exact position is is easy calculated, offcource the access will be little
bit slower than normal array.....
WHAT HAPPEN with HASHES ?!?
May be we can look at them as TABLES...
=====
iVAN
[EMAIL PROTECTED]
=====
