Front page | perl.perl6.internals |
Postings from June 2002
Re: matrix design
Thread Previous
|
Thread Next
From:
Ben Evans
Date:
June 19, 2002 05:51
Subject:
Re: matrix design
Message ID:
20020619124812.GA20939@parasolsolutions.com
Josef,
OK, I have to confess, I'm still probably thinking in quite a perl5ish
way about all this, but I'm just not convinced by the need for Parrot
to support matrices.
On Wed, Jun 19, 2002 at 10:03:43AM +0200, Josef H??k wrote:
> Ok now what do you think of representing matrices as below:
>
> Pointer to array of pointers of pointers, with the array elements
> pointing to the first element in the rows of each matrix and each element
> in the rows in turn pointing to a pmc.
>
> I havent thought alot on how we should do operations with this matrix
> reprsentation but we could (?) look at pmc->cache.int_val per default on
> each row element.
It needs to be made clearer what is meant by operations with the
matrix. Are we talking about operator overloading on +, *, -, etc? If
so, what about /? Including division or inversion opens a large can of
worms, yet is more-or-less necessary to do any serious work with a
matrix library.
Without inversion, it's an awful of lot of dogwork for what seems to
me quite little benefit. Which is a shame, because inversion is a
nightmare for arbitary-sized matrices. The algebraic techniques which
'should' work are slooow, and the iterative ones can be very sensitive
beasts indeed.
[There are also issues of precision. For example, the algebra of 2x2
matrices that is used in Macromedia's Flash are represented as fixed
point integers (eg 8 bits above and 8 bits below the decimal point).
It only takes about six multiplications before precision is lost, when
transforming a reasonably-sized object, using best-available
roundings and casts. The only thing which saves this from producing
visual artifacts is the fact that Flash uses a 20x20 grid to represent
each pixel, so it take a longish while before the effect can
become visible.]
It seems to me like an awful lot of work to implement all this in
Parrot, and I'm not sure what the benefits are. But that might be just
me. Oh, and if people do want to implement it, I can always be bribed
with beer to rant about My Matrix Hell....
> Reference
> Numerical Recipes in C
> William H. Press, Brian P. Flannery
> Saul A. Teukolsky,William T. Vetterling
Um. I hope that people know exactly how badly-regarded that work is by
modern standards. It's fine for basic concepts, but the C is
horrendous, spattered with global variables for no adequately
explained reason and is generally rather twitchy.
If anyone is seriously suggesting trying to make Parrot / Perl into a
language for numerical computing, my advice would be:
* Dont. You won't be able to get near the performance you need for
hardcore computing.
* Dont reinvent the wheel. There is a goodly chunk of prior art out
there.
* Dont use Numerical Recipes as a starting point. The quality of the
code in it is just not high enough, and many of the routines are
quite badly numerically unstable.[1]
Ben
[1] The cynical might suggest that the treatment of instability in it
is deliberately vague so as to try and prevent the reader from
applying it to any of the code in the book.
Thread Previous
|
Thread Next