I have just finished reading "Perl 6 Essentials". It was much appreciated and I proceeded to the perl6 web site to check out some changes that make perl useful for tasks other than practical report extraction. In particular, things mathematical. When I saw the wide array of math functions - versed sine zB - and element-wise operations on lists, my mouth began to water like it did when dad bought me my first K&E slide rule.
But I have some problems with what I see. RFC 82 hints at my plight with this: >The first source of discussion was around whether there is any consistent meaning to >array operations. The source of this was that some felt that other people may want >C<*> to mean something other than element-wise multiplication by default (e.g. matrix >inner product). However no-one actually said that I<they> wanted it to work this way, >only that I<others> may prefer it, particularly mathematicians. This physicist wants it that way. In scalar context $dotproduct = @A >>*<< @B; ought to return the scalar (dot, inner) product of vectors @A and @B by which I mean the sum of the products of like components. In array context it is quite reasonable to return the element by element products but it will be for accounting rather than for electrical engineering, mapmaking, and 3D rendering. @C = @A >>+<< @B; returning the vector sum is mathematically correct. An intrinsic ability to figure the dot product is useful for matrix multiplication. RFC 82 offers a mathematically abhorrent example of element by element "matrix" multiplication: > my int @mat1 = ([1,2], [3,4]); > my int @mat2 = ([2,2], [1,1]); > my @mat3 = @mat1 * @mat2; # ([2,4],[3,4]) Perhaps the designations "mat1, 2, 3" are not intended to be abbreviations for the word matrix but it is dangerous indeed to provide a syntax that will surely be confused with true matrix multiplication. @matC = @matA >>*<< @matB should produce elements in the result which are the dot products of the row vectors of the left matrix with the column vectors of the right. Note that one or the other of the input matrices needs to be transposed and some standardized notation is required. Matrix multiplication is not commutative. The apocalypse at <http://dev.perl.org/perl6/apocalypse/A03.html> has this to say about confusing people. >Anyway, in essence, I'm rejecting the underlying premise of this RFC (82), that we'll >have strong enough typing to intuit the right behavior without confusing people. >Nevertheless, we'll still have easy-to-use (and more importantly, easy-to-recognize) >hyper-operators. And then it goes on about other vector-like things:. >This RFC also asks about how return values for functions like abs( ) might be >specified. I expect sub declarations to (optionally) include a return type, so this >would be sufficient to figure out which functions would know how to map a scalar to a >scalar. There is the norm of a vector, actually the length if we're talking about 3 dimensional geometry, which can be considered the abs(@A) as a scalar. It would be the positive square root of the sum of the squares of the components. = sqrt ( @A >>*<< @A ). It would also be possible to include a scalar norm of a matrix which would be its determinant but that's probably fodder for a module dedicated to solution of linear equations. The mathematical talk continues in <http://dev.perl.org/perl6/exegesis/E03.html> with: >Substitute our vector, Victor! And then goes on to talk about the interpretation of @array as a perl 5 scalar count of elements which might well be strings rather than numbers. I think the meaning of "vector" here really is an array of usually 3 elements in a coordinate system but it's not terribly clear. In computer science, the term has also been used for what we now call a pointer to a memory location. An element by element concatenation of two arrays of text is certainly reasonable. As a multiplication I'm not sure what it would mean but it's a bit like the @mat1 >>*<< @mat2 in the quote above. Not very interesting or useful. Whatever be the final result for perl 6 syntax it ought either to use the terms matrix and vector as employed by the likes of Maxwell and Heisenberg and provide mathematically correct operators or it should avoid those terms when documenting hyper-operators that do something else. And then there are those two-component vectors which are complex numbers. . . and vector cross products. . . and quaternions. . . I am officially retired with some time but I have yet to process my first CVS file and, though I do C, there is a long learning curve for this guy who started when FORTRAN was a pup. Is anyone interested enough to encourage me? What can I do? I run Mac-Darwin and Linux. [EMAIL PROTECTED] http://www.macnauchtan.com/ -- --> The best programming tool is a soldering iron <--
