On Fri, Jan 23, 2004 at 05:20:41PM -0700, Doug McNutt wrote: : I have been a lurker since early November. Dan S. suggested I get over : here when I wrote a piece on the summary list describing my feelings : about vector operations in perl 6. My information was based on the : recent O'Reilly book and I had to confess that I have never in my : life opened a CVS file. I did volunteer to help and I remain willing.
Appreciate that... : Luke Palmer also responded to my message and said I would be horrified : to learn that >>*<< was being called a "vector" operation rather : than a "list" operation. I am horrified. Computer scientists have : already usurped the terms "real", "kilo", and others and given them : non-standard meanings. Please don't do the same with "vector" and : "matrix". And forget I ever mentioned quaternion, tensor, and rotor. Sorry, I was just copying the designers of supercomputers in my terminology. So you can really blame Seymour Cray for misappropriating the term. On a Cray, "vector processing" is just operations applied in parallel to two one-dimensional lists. Unfortunately, I don't think you'll be able to get an apology from Seymour Cray these days... : I am a physicist and mathematician who uses perl5 extensively for the : likes of preparing CAD data for printed circuit board fabrication and : creating AutoDesk files in DXF format from mathematical calculations. I : even plot data on my web site using perl to create .SVG files. I : learned to code when FORTRAN didn't have any version number and I : still think I might be happy with pure assembly in parrot but when : I want to do vectors or complex numbers I end up in Waterloo Maple : for the solutions and M$ Excel for the arithmetic. Perl 6 would sure : be nice for once-in-a-while vector operations that are not worth the : programming time for an array of 1024 Mac G5's. I'd like the program running on the array of 1024 Mac G5's to be in Perl too. :-) : This whole thread worrying about semantics of obscure operators for : things that are not even going to be real vector or matrix operations : worries me. Just who do you think is going to use them? Multiplying : elements of an array by each other to get another array is not a vector : product and it is not an inner product. It is useless to me regardless : of the operator syntax you choose. Ditto for multiplication of lists : of lists, also called matrices, where all you do is provide piece by : piece multiplication of elements. The so-called vector operations in Perl 6 are not really aimed at mathemeticians. They're aimed more at the image processing and finite-state automata folks, who often want to do the same thing in parallel to a bunch of different array elements. This is why they may be applied to any operator, not just numeric operators, so that people can do things like "append newline to every element of this array" without writing explicit loop or map statements. Not being a mathemetician myself, it has always been my intention to let the mathemeticians define their own operators however they see fit. That is why Perl 6 allows the definition of Unicode operators. : In FORTRAN I learned that names that begin with IJKLMN were integers : and further that if only a single letter is used it will be assigned : to a hardware register. Those letters are what you now call a sigl : and I'll bet I spelled it wrong. : : Why can't you assign a sigl to things that are to be vectors : or matrices and let that determine what the standard operators : do? Context could distinguish the inner product from the vector : product. typedef? Those of us who actually use vector arithmetic : wouldn't mind a special identifier that's not an $, @, or %. Other : users need not know about it until they find it useful. If absolutely : necessary to comply with modern terminology you could call vectors : and matrices members of a class and overload the operators but my : experience is that such things just cloud the underlying arithmetic : process that needs to be foremost while solving a problem. You are precisely right: "Other users need not know about it until they find it useful." In this case, I'm one of those other users. :-) That is why, not being omniscient, I will leave it to the mathemeticians to define their own sigils. Unfortunately, most of ASCII is used up, so you'll have to pick your sigils from Unicode. But part of the design of Perl 6 is that the language be mutable enough to make this trivially easy. A single declaration can turn Perl into Swahili, as far as I'm (un)concerned. "All is fair if you predeclare." : The KISS principle is important. Please reconsider your "vector" : operations before you go off the deep end with syntax that won't : ever be used. I believe they will be used, but maybe not in your realm of endeavor. The entire universe does things in parallel, so I think it behooves Perl to provide some way to specify that without iterative constructs. I really only care about the concept--I don't give a rip about the word "vector". I can let it go at the drop of a hat. Because of the confusion engendered by overloaded use of the term "vector", I've recently taken to calling them "distributed" operations instead. But that's a mouthful. Maybe we need to make up a new word. But "dwimops" is a bit too general. Parops, genops, hmm... Maybe we should go back to "hyper ops". On the other hand, we could teach the mathemeticians not to assume that their usage of a word is the only usage. :-) And many people do think vector is the opposite of scalar... : And yes, I have some time and would like to help. But : it will take hours to learn about the C++ stuff in CVS files. I have : Linux and Mac OS neXt available. It would be useful to me to find out which Unicode characters a typical mathemetician would actually find useful. I don't actually know, for example, what the preferred operator for outer product would be. APL used the circle operator, but there are a number of multiplicative operators defined in Unicode, most of which seem pretty abstruse. Eventually I'd like general feedback from the viewpoint of the mathemeticians on the design of overloading, multimethods, and various forms of syntactic relief. Up till now I really only have the input of the PDL folks in RFCs 202..207 (available on dev.perl.org), and some of the design has been influenced by those RFCs already (such as syntax of slicing). But a lot of this feedback will have to wait for Apocalypse 9, which will come out sometime after Apocalypse 12, which will come out sometime...soon... Larry
