Re: Commensurability as Key
At 20:27 -0700 8/20/13, Jonathan Lang wrote: Off list accidentally I think. Could you try to put commensurability into layman's terms? Preferably with a focus on some of its less obvious advantages. On Aug 20, 2013, at 8:19 PM, Doug McNutt dougl...@macnauchtan.com wrote: At 11:41 -0400 8/20/13, yary wrote: I'll bite... this concept of commensurablity is not one I grasp from your email. functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. Perl many other languages don't have a strong distinction between functions procudures (as I'm sure you know), * a function is a subroutine returning a scalar ( see below) , a procedure is a subroutine with no return value, side-effects only. A subroutine returning many values- a parcel of containers, perhaps, or an iterator, etc- is a many-to-many relation. I understand relational algebra from decades of SQL work, and have seen ORM's replicate relations in object systems with some success. What's missing for creating a relational wonderland in perl6? I confess. I'm here because I hoped perl 6 would do vector operations after reading an early small book. I would really like to see perl support a function called a cross product that would return a vector, the product of amplitudes and the sine of the angle between them, as a vector using the notation. That's not a scalar! But i surely would be commensurate with the input arguments. It's still FORTRAN forever for physics, electrical engineering, and global warming. Commensurable has a meaning in integer arithmetic that pretty much means that two integers have a common factor. If they appear as numerator and denominator of a fraction that fraction is reducible by dividing both by the factor. In the physical sciences commensurable refers to numerical quantities that can be legitimately compared as if they were results of an experiment. In most cases the numbers have units of measure associated with them. 2.54 centimeters is rightly compared as equal to 1 inch even though 2.54 is not an integer and it's certainly not equal to 1.00. For a 3-D vector to be equal, less, or greater than another 3-D vector only if the two vectors refer to the same variable which might be velocity, position, or acceleration. The units must match if comparison is needed. Acceleration might be ft/sec/sec for one vector and meters/sec/sec for another and they could be reasonably compared but finding a programming language that handles that automatically is a PITA. I sort of remember, on this list, some work with allowing numbers to have units. I think it got lost. O'Reilly Perl6 Essentials (2003) on page 37 introduced vector operators in the form + which represents vector addition with an example @sums = @first + @second. I took that to mean that @first was a three element list of the x, y, and z components of a real vector. I assumed (foolishly) that meant there would be a X and a . which would return cross and dot products. I even thought about the 4-vectors of relativity where the fourth component is time multiplied by the velocity of light.. But it was not to be without getting deeply into the process of compiling. My home built subroutines do it in perl 5 and long ago they worked with FORTRAN without any numbers after the name. The term vector has also found meaning in programming. C calls that a pointer and other languages call them references. All point to something else. I think James Bowery's comments are intended to address a real need for programming languages to work with units of measurement. It might even prevent aircraft accidents which have really happened because fuel was delivered in Canadian gallons, or kilograms, when the pilots request was for American pounds in his owners manual. Commensurable purchase orders would be nice. -- Fe++ // \ Fe++ Fe++ | || Fe++ Fe++ \\/ Fe++
Re: Commensurability as Key
At 11:41 -0400 8/20/13, yary wrote: I'll bite... this concept of commensurablity is not one I grasp from your email. functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. Perl many other languages don't have a strong distinction between functions procudures (as I'm sure you know), * a function is a subroutine returning a scalar ( see below) , a procedure is a subroutine with no return value, side-effects only. A subroutine returning many values- a parcel of containers, perhaps, or an iterator, etc- is a many-to-many relation. I understand relational algebra from decades of SQL work, and have seen ORM's replicate relations in object systems with some success. What's missing for creating a relational wonderland in perl6? I confess. I'm here because I hoped perl 6 would do vector operations after reading an early small book. I would really like to see perl support a function called a cross product that would return a vector, the product of amplitudes and the sine of the angle between them, as a vector using the notation. That's not a scalar! But i surely would be commensurate with the input arguments. It's still FORTRAN forever for physics, electrical engineering, and global warming. Sigh. -- -- Perl is the ductape of the internet. --
Re: dimensionality in Perl 6
At 16:58 -0800 11/18/10, Jon Lang wrote: If this is implemented, Duration should be an alias for something to the effect of Num but unitssecond. Otherwise, Instant and Duration remain unchanged. Thoughts? http://www.physics.nist.gov/cuu/Units/index.html with special attention to: http://www.physics.nist.gov/cuu/Units/binary.html When a user multiplies two dimensioned quantities the result should be assigned the product of the dimensions of the factors. E = m*c**2 should acquire the dimension kg*m^2*s^-2, a joule. Comparison of that with another energy unit, like a BTU calculated from temperatures, should return an error unless some user selected add-in, which might well have a political flavor, is asked for. -- -- A fair tax is one that you pay but I don't --
Re: meaning of range - use interval instead?
At 15:08 -0700 9/23/10, Darren Duncan wrote, and I snipped a bunch: Larry's updating the Synopsis terminology to say sequence instead of series for correctness led me to check out what seems to be a similar problem, range. Add to the list of meanings, in the world of computing, Microsoft Excel's use of a range object to represent a collection of worksheet cells, usually rectangular as (A1;Q10), as either a left or right item in a command. Like it or not there will be users of perl-6 who also use Excel or one of its equivalents in the open source community. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
OT: Yahoo web mail
Since January 2009 I have accumulated over 1000 messages to groups, that arrived with improper 0A (UNIX line ends without a preceding 0D) in the body of the message. In order to reply to such a message I have to remove them manually to avoid rejection by my SMTP server. It's a PITA. I have tracked the problem down to Yahoo's web based email client. A bug has been filed with Yahoo on its internal Bugzilla system. Details of the indictment are at http://macnauchtan.com/editorials/QuotedPrintable.html. It's interesting that a particular poster, From: Ovid publiustemp-perl6langua...@yahoo.com, is using a Yahoo address and may not be going through a web interface. Please, off list replies to address in the link unless useful to other listers. -- -- There are 10 kinds of people: those who understand binary, and those who don't --
Re: Suggested magic for a .. b
Please pardon intrusion by a novice who is anything but object oriented. I consider myself a long time user of perl 5. I love it and it has completely replaced FORTRAN as my compiler of choice. Programming Perl is so dog-eared that I may need a replacement. I joined this list when I thought the ... operators might allow for vector operations like cross product. dot product, curl, grad, and divergence. I was mistaken but was pleased that such things would be possible as add-ins to be created later. I have never used the .. operator on perl 5, mostly because I can't understand it. I have actually wished for, in perl 5, an ability to create a list, really a unsorted set with an @theset kind of description that I could create with a regular expression. All ASCII strings that would match would become members of @theset. @theset = /\A2N\d\d\d\d\Z/; would make create a temporary array of transistors that have 2N, once military, designations. That list would become an input to some other code that would look for datasheets. Memory intensive but easy to understand. Are you guise sure that the ... and .. operators in perl 6 shouldn't make use of regular expression syntax while deciding just what is intended by the programmer? -- -- The best programming tool is a soldering iron --
Re: Proposal for a new Temporal time-measurement paradigm
At 21:09 -0700 4/23/10, Darren Duncan wrote: I think that the most thorough solution is to just take it for granted that there are multiple reference timelines/calendars and that in general it is impossible to reconcile them with each other. At 15:46 -0700 4/24/10, Darren Duncan wrote: All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). At 19:25 -0400 4/24/10, Mark J. Reed wrote: Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. Please accept a plug for Darren. With all of the political and religious problems associated with calendars I would really like to see perl step aside and do ALL of that in modules or perhaps with use of libraries and methods provided by the operating system in which perl is a current process. Atomic seconds per mean solar day is not a constant and might be changed by political action. Mean solar days per year is determined by your God who tells the earth how fast to spin. Ditto for atomic seconds per year. Days in a month is so screwed up that folks argue about age of children when qualifying for benefits. Please just give up and get perl 6 running without trying to lead the world. Make it easy to set up optional schemes as particular users require. Use the epoch as defined in the operating system or, if undefined, use the start of 1970. You could take the instant of perihelion in what Gregorian people think was 1970 years after some important instant. Well, perhaps is was 1969 years if was Roman numeral I. Do everything in a way totally independent of earthly coordinates of the computer in use. But do assume it's motionless with respect to Earth in a 1 g field perhaps at Greenwich UK or Fort Collins CO. Agree on a format for storing fractional atomic seconds. There are proposals for two word integers with one of them being micro or nano seconds and the other seconds. I prefer IEEE floating point with atomic seconds as the unit of measure. That's a bit like MS Excel where days are used for the unit. The Excel scheme is not as clean because it assumes 86400 seconds in a day and it's a day off between what it thinks was Feb 29, 1900 and its epoch at the start of 1900. In any case users need a time value that can be negative or large positive. It's OK to lose precision for time points a long way from the current epoch. Floating point handles that nicely. We really don't care what day of the week the big bang started on but we really would like to use whatever time system is standard to perl. We'd also like to record time differences between collisions in the new CERN accelerator or the arrival times of entangled photons. Easter is the first Sunday after the first full moon after the vernal equinox - - - except. Some pope ordered a calculation of the date for some 3000 years in advance. He blessed the result. So the rule holds except for the mistakes made 1000 years ago. I learned that in 1961 which is the only year of error in my lifetime. Please don't ask perl 6 to pontificate on things like that. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: underscores vs hyphens (was Re: A new era for Temporal)
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include - in the list of characters
that are considered words when double clicking? When doing a find and replace
all as words?
Is the unicode equivalent of nbsp; allowed in a variable name?
--
-- Give me liberty or give me Obamacare --
Re: numerics, roles, and naming
At 10:25 +1300 3/17/10, Martin D Kealey wrote: On Mon, 15 Mar 2010, Mark J. Reed wrote: Anything that can be made into a list is discrete. Not quite, since you can create lists whose members belong to continuous sets, e.g. real numbers. Anything that naturally forms a list, maybe. A discrete non-finite set is isomorphic to the set of integers. This implies that you can pick an ordering, although perhaps not one that is computational useful. E.g. rational numbers can be mapped onto integers by laying them out in a 2D array, much like Gauß's complex integers, and then walking diagonally in one quadrant. If you have more than one quadrant, take them in turns. Extends to 3D and higher in a logic fashion. aleph 0. In the world of real (pun intended) computers there is no continuous set of real numbers. Microsoft Excel users are regularly reminded of that when they report bugs that are nothing more than the impossibility of representing 0.1 (10) as an IEEE float. Perhaps everything is discrete in the set of things that perl is expected to deal with. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: numerics, roles, and naming
At 18:14 -0800 3/14/10, Jon Lang wrote: There are discrete things that are not ordered (such as gaussian integers), and there are ordered things that are not discrete (such as real numbers or strings). The word discrete as in atoms are the discrete view of matter may turn out to be confusing to a class of calculus trained folks. Anything that can be made into a list is discrete. The other option is a function in the sense of the calculus that truly has an infinite number of values. Computers don't deal with that kind of thing except, perhaps, in the likes of Mathematica and Maple where ROOTOF( ) is used to represent something that cannot be calculated right now. I really don't think perl should be getting into that. But there is a discrete Fourier transform that is never exactly the same as a Fourier transform done with the techniques of integral calculus. Perl6 surely will be performing the discrete kind but will the arguments and answers need to be discrete variables? They will surely be lists of, often complex, numbers. Perhaps the term atomic could be discreetly considered in place of discrete. -- -- A fair tax is one that you pay but I don't --
Re: Comments on S32/Numeric#Complex
At 11:54 -0800 12/17/09, Jon Lang wrote: And I think there's a Math error in the 4th line: you don't need the components of a vector to do a dot product with that vector -- so it is just my ($x, $y) = $vector «·« ( [1, 0], [0, 1] ); True enough. Which makes me wonder if all of them are just the dot-product of an object with a role (i.e. it uses the .^attr of the role, not the object): I became an observer a few years ago when vector operations were being introduced in perl6. I was excited, thinking that perl6 was actually gong to do mathematics. After a while I became resigned to the fact that dot and cross products were not what was being offered. Instead a product of two vectors was to be simply a component by component multiply that produced another vector of the same size as the arguments. It appears that is what is being done in the formula above. OK. Perhaps there really are uses for that operation in the computing world. But please don't call the result a dot product! It will be misinterpreted forever in the same way that the term kilo was forever made ambiguous when computer types decided it meant 2**10 instead of 10**3. Dot and cross products have been around since Newton. Kilo since the mid 1800s. Phase is a good name for the angular part of a polar complex number. It's actually used that way by electrical engineers working with three phase power distribution. But those guys also expect a dot product to be a scalar which is the sum of the products of the vector components. True power is charged for by computing the dot product of voltage and current vectors expressed as complex numbers. That requires the original meaning of the dot product. $dotproduct = @vector1 . @vector2; In scalar context would be nice but it can come later as an add-on. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: Comments on S32/Numeric#Complex
At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? In pre-computer times the angle was called the argument. But that offers plenty of room for confusion in the current contest. -- -- So do we celebrate the start of a new decade at the end of this year? Or do the tens start at in January 2011? Was the first year, ACE, assigned Roman numeral I ?--
Re: Logo considerations
You folks should really consider the oyster as perl's mascot. The mother of pearl relationship is too good to pass up and I'll bet that someone will come up with a bi-valve operator soon. -- -- A fair tax is one that you pay but I don't --
Re: Comparing inexact values (was Re: Temporal changes)
I don't know how relevant this is; but this sounds like the sort of optimization that pure functional programming allows for - that is, if the compiler ever sees a call like asin(sin($x)), it might optimize the code by just putting $x in there directly, and bypassing both the sin and asin calls - but only because both sin and asin are pure functions (i.e., they don't produce any side effects). Don't get too hung up on that example. If $x is 2*pi, asin(sin($x)) would return 0.0 and not 2*pi. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: Comparing inexact values (was Re: Temporal changes)
At 13:58 -0500 2/25/09, Mark J. Reed wrote: I do quite like the magical postfix %, but I wonder how far it should go beyond ±: $x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ? $x * 5%; # becomes $x * .05 ? For ratio-like comparisons for effective equality of floats some thought might be given to operating on the mantissa part of the IEEE float. For normalized floats it's possible to get nearly equal tests by simply truncating the mantissa at some number of bits and comparing the floats as longs for equality. I suspect most technical users would have no problem in specifying a number of significant bits. They certainly can do it with decimal digits. Rounding from 52 to, say, 16 bits ought to be easy in binary. But then with everyone using processors with floating point hardware the efficiency might not be important. -- -- Marriage and kilo are troubled words. Turmoil results when centuries-old usage is altered in specialized jargon --.
Re: Comparing inexact values (was Re: Temporal changes)
Thinking about what I actually do. . . A near equal test of a float ought to be a fractional error based on the current value of the float. $x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 - $errorfraction) If you're dealing with propagation of errors during processing of data the fractional error is usually the one that's important. Finances might be different but floating dollars have their own set of problems relating to representation of decimal fractions. -- -- A fair tax is one that you pay but I don't --
Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
At 11:42 -0600 2/22/09, Chris Dolan wrote: Floating point time would be cooler. :-) And it has been in use by Microsoft in the Excel spreadsheet since the Apple Plus which didn't have floating point hardware. But then Excel uses the day as the unit. the second would be better.
Re: Smooth numeric upgrades?
On Sunday, 5. October 2008 04:23:42 Darren Duncan wrote: Note that just as integers are naturally radix independent, the unlimited rationals should be too, and the latter can compactly represent all rationals as a triple of integers corresponding roughly to a (normalized) [mantissa, radix, exponent] triple; with that approach you also get unlimited floats for free, so no reason to make floats an exception where they aren't unlimited where integers and other rationals are; after all, what is a float or scientific notation than just another notation for a rational value literal. At 18:06 +0200 10/5/08, TSa (Thomas Sandlaß) wrote: I want to stress this last point. We have the three types Int, Rat and Num. What exactly is the purpose of Num? The IEEE formats will be handled by num64 and the like. Is it just there for holding properties? Or does it do some more advanced numeric stuff? Another matter is how to represent irrationals. With IEEE floats which are basically non-uniformly spaced integers imprecession is involved anyway. But sqrt(2) is a ratio of two infinite integers. How is that handled? Here I see a way for Num to shine as a type that also involves lazy approximations. But then we need a way for the programmer to specify how these approximations shall be handled. I'm not so sure that sophisticated numbering is necessary for a practical extraction and report language. But. . . Symbolic algebra packages handle irrationals like sqrt(2) with a root of function which can be included in a result before it is deliberately converted to an approximation in a later step. Perl should NOT do things like that. As for unlimited precision in floats I'd rather see a floating point number triple that includes, in its structure, an estimate of error, and physical units. Multiplying amperes by volts would then return watts with an appropriately calculated estimate of the error. Testing for zero would include the error estimate. When I work with data from the power company expressed in MMBTU I can add to a working table of units that MMBTU translates to 10^6 BTU because the M means 1000 as in millia pasuum. I could also provide a conversion from BTU to joules and have it properly handled. Many arithmetic errors are the result of not keeping the units inside of the evaluation. The result is newspaper articles that confuse energy and power as they extract from data provided by power company engineers. 1 kW per day is meaningless. I wonder if they use perl to extract the data. And what are those two infinite integers? I wonder if there is a series that expresses each one? -- -- A fair tax is one that you pay but I don't --
Re: cross operator and empty list
At 09:58 -0700 4/14/08, Larry Wall wrote: By the way, you don't need to put parens around the arguments to X. It takes a list on either side. We made it tall so that it would stand out visually anyway: $a,$b,$c X $x,$y,$z How long before some engineer or 3D graphic artist gets really frustrated when he doesn't get what he expects? ($a,$b,$c) X ($x,$y,$z) --- ($b*$z - $c*$y, $c*$x - $a*$z, $a*$y - $b*$x) use classic_vectors; # perhaps. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: Musings on operator overloading
At 09:46 -0400 3/27/08, Mark J. Reed wrote: Is it just me, or is all this talk about precedence and functions vs operators vs methods creating a niggling sensation in anyone else's head? It feels like we're in the vicinity of another one of them Big Simplifying Idea things. Unfortunately, I don't have the actual Big Idea, so it could just be a false alarm. At 16:24 +0100 3/26/08, TSa wrote: I agree. But let me explain how I arrive at that. To me there is no binary minus! -f(x) - g(x) = -f(x) + -g(x) = -g(x) + -f(x). I.e. plus is commutative. In other words overloading unary minus gives you the binary version for free. Or even better is to deeply overload unary plus to do the Ring role. Additionally implementing unary / or 1/ or so would yield the Field role. At 17:06 +0100 3/20/08, TSa wrote: BTW, do we have a unary multiplikative inversion operator? That is 1/ as prefix or **-1 as postfix? Perhaps .inv as method? Do we have .neg for additive inversion? This is becoming a night time habit. I really need to spend a whole lot of time learning the new operator syntax and Perl 6 Essentials 1st edition isn't going to cut it. Following Mark's line of thought, that bothers me. Thomas' idea that there is no such thing as a binary minus operator and his question about inversion operators intrigue me. Perhaps there is a way to a breakthrough that would be acceptable to long-time users of the chalkboard and still be mathematically pure and and easily parsed. A while back there was a flurry of new math being taught in US elementary schools. The idea was to introduce set theory early and avoid the re-learning necessary when groups and fields are introduced later. It was a failure mostly because the teachers couldn't understand it. A group is a set with a single binary operator defined, the result of that operator is a member of the group, there is a null member of the group that returns the value of the other operand, and every member of the group has an inverse for which the operation returns the null. Note that those axioms say nothing about an inversion operator. For numbers the operator is either addition, +, or multiplication, *. Subtraction and division are notably missing. A field is a set which looks like two kinds of group with two operators. One operator has higher precedence than the other and the existence of the inverse for one operator requires some modification for the null of the other operator. Matrices and vectors are reasonably comfortable in fields. Note that commutativity is not a group requirement. The vector cross product is a bit strange but some folks claim that a cross product is really an antisymmetric tensor that isn't really a vector because it doesn't transform, under reflection, as the coordinate differentials. That kind of thinking would fit right in and might be beneficial. Overloading code would be required for * and + only but inversions would replace that bit of simplification. Note that the term class acquires a close relationship with the term field. I think it is possible to insist that users of perl 6 for math think in terms of fields while writing expressions. Just remove the / and - operators from the language. They're not present in the field axioms so why have them? Just announce that perl 6 will be different. The rest of the world now listens when we say a perl regular expression. Why not the same for perl math expression ?. NIST now likes people to avoid the term per when writing about dimensions of physical quantities. A watt is a kg*m**2*s**-2 when translated to perl 5 but it looks a lot better in print with superscripts and no explicit * operator. Calling it a kilogram meter squared per second per second has been deprecated for years. Engineers and physicists known to me have no problem with it. There was once a mnemonic, PEMDAS, that was taught in algebra classes. Parentheses, exponentiation, multiplication, division, addition, subtraction was the order to use when working with algebraic expressions. Restricting that to fields would change it to PFMA by which I mean parentheses, functions, multiplication, addition. Functions would include exponentiation along with other things like inversion and more complicated library functions.. Users would have to learn that division and subtraction would be called out by an inversion followed by a multiply or add operation. Terms on the right side of the replacement operator would be separated by + signs only. Needed would be a really simple syntax for the two types of inversion. Something like a distinct sigl would be nice from a user's point of view. $xxx[$n] is closely associated with @xxx and it seems possible to come up with something like Nxxx for the additive inversion of $xxx and Dxxx for its multiplicative equivalent. Variables starting with I through N was not a bad way to indicate an integer. I haven't any idea how one would request that a function
Re: Musings on operator overloading
At 21:40 +0100 3/25/08, TSa wrote: Doug McNutt wrote: Don't allow it ( = - f($x); )to become = f(-$x); ## wrong! Unless of course f does Linear, then you can factor out or in the multiplication with -1 at will. So linearity of operators and functions is a very interesting property for optimizers. Well. . . I was going to let it pass but I had trouble sleeping this morning because of it. f($x) = constant + $x would certainly be considered a linear function with constant derivative but for that definition -f($x) is not the same as f(-$x). I think the appropriate term is antisymmetric to indicate -f(x) = f(-x). Examples would be sin(x), pow(x,3), 1/x, x**3. What worried me in the night is a comment in the Camel book that says the ** operator has a higher precedence than the unary minus with the clear implication, unfortunately true, that other languages declare the opposite. If that structure will persist into perl 6 there is a real danger that new postfix operators that are being talked about, multiplicative or additive inversion for example, may well need to be declared either symmetric or antisymmetric to keep an ambitious parser or optimizer under control. What is really needed is a more careful detection of the unary minus. In chalkboard algebra there is no such thing as a unary minus in an equation. A leading minus, one that follows an = sign or a left parenthesis, is interpreted as an implied subtraction from zero or perhaps an implied multiplication by negative unity. The unary minus only shows up in things like a list of numbers, the components of a vector (-1,2,-3) or numeric values arriving over a teletype link.. I think, but can't prove, that the discrepancy began with compiler compilers - yacc - where GUI programmers - Excel - saw an easy way to put formulas on a video tube. All they had to do was provide operator definitions and precedence rules. One possibility is to decide that unary minus does not exist in a replacement expression. Perform a clear and subtract assembly instruction. That would not matter for a common programming technique that defines a constant $negpi = -3.1416; instead of a real unary minus using *NEGPI = \-3.1416; or use constant NEGPI = -3.1416;. It's needs some updating but http://macnauchtan.com/pub/precedence.html is still on the net. The statements: = - f($x) - g($x); = - g($x) - f($x); should always return the same result regardless of whether f or g is implemented as a function, a method, or a postfix operator; and that should be true even if the - operator is overloaded. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: Musings on operator overloading
At 17:06 +0100 3/20/08, TSa wrote: BTW, do we have a unary multiplikative inversion operator? That is 1/ as prefix or **-1 as postfix? Perhaps .inv as method? Do we have .neg for additive inversion? There certainly is the unary minus even though it is badly interpreted in some languages, thankfully NOT including perl 5. Don't even think about parsing = -$x**2; so that it returns a positive result. Perl 5 handles it by assigning a higher precedence to ** than to addition. The real fact is that the minus sign in the above formula just isn't a unary minus in chalkboard algebra. = $a - $b - f($x); when $a is known to by identically equal to $b should be the same as = 0 - f($x); or just = - f($x); which happens easily with pencil and paper. Don't allow it to become = f(-$x); ## wrong! even if the f() is really written as $x**2 or has some other postfix operation - inversion - that's considered a function by a mathematician. * At 15:01 +0100 3/20/08, TSa wrote: BTW, operator overloading does not allow to change the precedence, associativity and commutativity of the operator because these are parser features. A vector on the chalkboard can be a row or a column but in a computer it's an ordered list with the vertical or horizontal order of the components residing only in the mind of the programmer. Multiplying a vector by a matrix implicitly indicates that the vector is a row. Multiplying a matrix by a vector implies a column vector and the results are quite different. =$vector * $matrix; is probably well handled in a overloading method because the order implies the rowness or columnness of the vector but it could get confused by a parser that has its own ideas about precedence and commutativity. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: Musings on operator overloading (was: File-Fu overloading)
At 17:30 + 2/24/08, Luke Palmer wrote:
On Sun, Feb 24, 2008 at 3:00 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
And I read both very carefully and failed to understand most of it.
I use perl for physics and engineering mostly because I forgot most of my
FORTRAN long ago and perl works everywhere.
I really want to use complex numbers, vectors, matrices, and sometimes
quarternions. I really want to be able to define or use previously defined
operators in a way that I learned in the 50's. I want my compiler to understand
when I use vectors in which the components are complex numbers. I want dot and
cross product to work. I want to be able to multiply a matrix by a vector and
get a polite error message if I try that with impossible arguments.
What I think I learned from those two messages is that it's damnably difficult
for a parser to figure out what I'm doing. Perhaps it just isn't worth while.
But. . .
I really don't mind informing my compiler in advance about what I want a
variable to be treated as. Typedef {}, Dimension () and the like are no problem
at all. I don't mind. And I think that would also apply to my scientifically
oriented friends.
Wouldn't it make life easier for the parser to overload the * operator into a
dot product whenever both arguments have been defined as vectors or been
returned as vectors by a previous operation? One could even use ** for a cross
product since raising to a vector power is unreasonable. Just recognizing the
special use declared and passing the operation off to a required subroutine
would be adequate. Yes. It can all be expressed in simple object-oriented
language but all of the File::Fu stuff is unduly complicating the use in
mathematics.
Practical Extraction and Reporting are what perl is about and I know I'm
stretching the plan but just a bit of code that will allow, but not require,
typedefs - er classes - of special things that cause operators to be passed to
subroutines - er class methods - to be written could make a big difference.
Even translating ^ to pow($x,$y) would be useful to some, but I remember that
much FORTRAN. And -2^2 is -4 (correctly?) in C on a two's complement machine.
--
-- Life begins at ovulation. Ladies should endeavor to get every young life
fertilized. --
Re: Some questions about using NaN and Inf
At 11:52 +0200 10/8/07, TSa wrote:
HaloO,
My understanding is that values like NaN or Inf are exceptional. That
means you can understand them as unthrown or in-band exceptions. Like
undef they might contain interesting information about their
origination. That being said I think these exceptional values should
not be re-inserted into the regular flow of computation by simple
comparison. In other words $x == NaN and the like should be undef.
That means that these values behave viral in the sense that more and
The only operator that can be used to investigate these values should
be ~~ and the given/when statement that uses it. This means we need
a standard set of e.g. NaN cases. Does someone know what IEEE defines
in that area? Here's a little code example illustrating my point:
if $x ~~ NaN
{
given $x
{
when DIV_ZERO {...}
when UNDERFLOW {...}
when OVERFLOW {...}
}
}
Also handling Inf is a difficult thing to do. In general Inf == Inf will
hardly hold. The first thing I would expect is Inf to be properly typed.
That is Inf[Num] is different from Inf[Complex] and for finite types any
number outside the valid range could represent Inf.
From this engineer/physicist's point of view the most valuable part of the NaN
concept is that NaNs can be passed to formulas and functions in a way that
avoids error checking altogether.
$B = Inf ( as the result of a previous calculation)
$result = $A / (1.0 + 1.0 /$B);
need not return an error because one of its arguments is an error. The result,
to the expected precision of floating numerics, is exactly $A. Such formulas,
usually much more complicated, do crop up regularly and it's a pain to have to
pre-check for out-of-range values in a tight loop. It's best not to trap that
kind of error but to let the calculation proceed to a result which might, or
might not, be out of range.
Vectors and complex numbers, which can be thought of as 2-D vectors with
different rules, don't really exhibit the NaN concept. A component can be a NaN
but nobody has defined what a whole vector as a NaN means. Asking whether one
complex number is bigger than another results in an answer that depends on the
user's intentions and is probably not something that should be frozen into a
compiler. Let the programmer do an OR on each of the components as desired. He
might really want to compare lengths of the vectors.
Remember that there are some 2**22 possible NaNs in the bit pattern of a 32 bit
float. Only a few are defined by the IEEE. It's possible to use others as
results of a specialized subroutine. The series didn't converge for instance.
= Inf - Inf; # should not return zero! Those two Inf's are not equal except in
some special circumstances that will not be known. They might be calculated
from the same series that didn't converge but that's a problem for the likes of
Maple or Mathematica. Nobody should expect perl to worry about that kind of
thing. Inf == Inf returning true would make this curious if $A = Inf and $B =
Inf.
$Y = (A$ == B$) ? 0 : A$ - B$;
Wikipedia for IEEE 754
http://en.wikipedia.org/wiki/IEEE_floating-point_standard is accurate. Actual
IEEE standards have to be purchased and they are not cheap. Even as a member I
don't get to see them for free and if I sound upset, I intend to. GNU forever.
http://en.wikipedia.org/wiki/NaN Discusses signaling and quiet NaN's. It
might be possible for perl6 to trap errors for the signaling variety and not
for the quiet ones but that's not a complete answer.
For a Practical Extraction and Reporting Language perl6 should probably adopt
Wikipedia as an authority and, as far as possible, avoid making new definitions.
--
-- Halloween == Oct 31 == Dec 25 == Christmas --
Re: propose renaming Hash to Dict
At 09:15 -0700 6/1/07, Larry Wall wrote: : To conclude, as hash definitely tastes better than a dictionary, we : should stick to that name. ;) : : At least nobody can say that Perl is bad taste! Then maybe we should rename Array to Skewer or Kabob or some such... Hmm, except it's hard to random access the middle... Maybe AntsOnALog... (celery, cream cheese/peanut butter, and raisins) Since Larry started it: Don't forget that a common form of hash as a food is SPAM in all capitals. Perhaps perl6 could get special dispensation from Hormel. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: Is Perl 6 too late?
At 11:43 -0700 5/14/07, Larry Wall wrote: In other words, the sigil is consistently a noun marker in Perl 6, even when a sigil is used on a verb. It would seem to me that a preprocessor, written in perl of course, could easily respond to DIMENSION noun AS double statements or whatever you like by adding the appropriate sigl every the noun appears without it. As for too late I do have a problem. I started with perl 4 or so as MacPerl with Apple's MPW as a shell. Now, at age 72, I do worry that perl 6 may be too late for me. It's been two years since I got to the point of using the * sigl in perl 5 and I still have a lot to learn about that. FORTRAN forever. -- Applescript syntax is like English spelling: Roughly, though not thoroughly, thought through.
Re: Numeric Semantics
At 00:32 + 1/23/07, Smylers wrote: % perl -wle 'print 99 / 2' 49.5 I would expect the line to return 49 because you surely meant integer division. Perl 5 just doesn't have a user-available type integer. % perl -wle 'print 99.0 / 2.0' OR % perl -wle 'print 99.0 / 2' would return 49.5 because a coercion was required and float is the default for such things. But that may be the mathematician in me. Computers often do things I don't expect. my $numer = 99 as INT; (You know what I mean. Perhaps a DIM statement?) my $denom = 2 as INT; print $numer / $denom; ??? -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: Numeric Semantics
At 17:35 +0100 1/9/07, TSa wrote: May I use this to remind the list that I proposed to define the modulus in the most algebraically pleasing way, i.e. in the Euclidean definition. (See http://www.cs.uu.nl/~daan/download/papers/divmodnote-letter.pdf) E.g. this modulus is also defined for Complex numbers. That is well worth reading from this physicist's point of view. 2001 is well before I found you guise. Integer part of a complex number tells which integral-radius annulus it's in. An interesting and likely useful concept. -- -- If it's not on fire it's a software problem. --
Re: Numeric Semantics
At 09:24 -0800 1/2/07, Larry Wall wrote: But I'm also still wondering whether a simpler approach is to declare that Num is a role that can encapsulate objects of class Int, Num, Rat, or Dec as necessary. There also a lot to be said for simple... Simple. . . YES! but I'm in no position to help. Computer science has left me way behind. But I do a lot of computing and I do like perl 5. In fact, I use it on Mac OS neXt in preference to C or FORTRAN. I fully understand floats, integers, complex, vectors, and big numbers and I believe that's typical of folks who really use computers for computing. It would be nice if perl 6 would allow me, the user, to specify in advance just which numeric type I want. Incompatible usage would be an error that would be politely objected to by the compiler. How about a convention that integers begin with I, J, K, L, M, and N while others are floats? Perhaps those letters by themselves would imply that they are indexing quantities which should be assigned to hardware registers. Yeah, that's just to show how old I am. But why not an optional typdef-like facility in perl which would tell the compiler what I want? It could even be an O-O style instantiation. Separate sigl's, perhaps but some unicode specials - questionable. User-defined sigl's in a pragma? DIM statements? $Lynn / $Jill would be an integer divide using whatever arithmetic logic unit the machine in use provides. $Ross / $Todd would be done with the floating point processor. $Ross / $Lynn would convert $Lynn to a float and return a float. See FORTRAN conventions to continue. -- -- The greenhouse effect due to water vapor has never been fully modeled and weather forecasting remains irreducibly complex. It is clear that global warming is the act of an Intelligent Designer. --
Re: renaming grep to where
Just a perl 5 physicist here. I had to run to the Camel book to find out that grep existed in the world of perl. But I have done this (from memory): $stuff_in_lines = `grep suntide *.txt`; I never thought about the potential for serious ambiguity in interpretation. The UNIX grep tool is really dissimilar considering that it uses a different regular expression syntax. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: RFC: Community Education Page
At 11:34 -0400 5/7/06, David K Storrs wrote: Hmmm...This doesn't seem to have particularly grabbed the popular imagination among the Perl6 crowd. I'm a lurker here, mostly interested in keeping perl 6 usable for mathematics and physics, but unable to keep up with most of the things I read. What I KNOW about perl 6 comes from Perl 6 Essentials First Edition, June 2003. That's how I got here. The + vector operators were giving me fits. I suspect there are copyright issues but an O'Reilly style bookshelf in an open source way that would provide continuous updates to Essentials would really be nice. I occasionally try to understand a thread by looking there but, at 3 years old, it rarely does any good. -- -- There are 10 kinds of people: those who understand binary, and those who don't --
Re: The definition of 'say'
At 21:30 +0100 2/8/06, Juerd wrote: Larry Wall skribis 2006-02-08 8:38 (-0800): It would be nice to have other data points In the Macintosh world: 1) say is a reserved word in AppleScript that sends text to a speaker (with windings and a cone). 2) We are forever mucking with $/ and $\ set to different values. One for reading someone else's file and the other for writing something the Macintosh way. (It's better in OS neXt.) And everywhere: 3) There are two more 16 bit line ends in unicode that may or may not ever be really used. -- Applescript syntax is like English spelling: Roughly, but not thoroughly, thought through.
Re: Indeterminate forms for the Num type.
At 09:38 +0800 1/18/06, Audrey Tang wrote: Also, would you be happy with different treatments of Int/Int versus Num/Num? 0/0 # fail illegal division by zero 0.0/0.0 # NaN I plead guilty. I was not aware that perl6 was going to allow types to be defined like int and float. While learning perl 5 I was frustrated by that lack at first but I came to like it after a while because the treatment of strings that happen to be numbers is well done. $serial = 48; behaves like a numeric 48 if I add to it but I don't have to perform an sprintf to get the zeros back if my goal is to repeat the value read from some HTML page or cookie. As a Gegenbeispeil try entering that or even a date in M$Excel. It will be immediately converted to a floating point seconds after the epoch and there is no way to recover the input text. I hate it. So. . . If perl6 will allow me to define a variable as type int64, int32, or things like that then division by zero should be an exception as should overflow on addition. If the perl way is the goal then users who don't want to go to C should be treated to $numerics that allows for strings, scientific notation, and the like while doing the right thing. For that, converting 0/0 to a floating point division with a NaN result is quite proper. The important thing is that ($aa + $bb)/$aa should return 1.0 when $bb is a NaN underflow or if $aa is a NaN Inf. Those may not be the best examples but you get the idea. Some intermediate results can return NaN's in a way that inclusion in a later calculation can produce a correct result in spite of the NaN. Numeric values often come from an external source. Unnecessary and confusing validation of that kind of input should not be required just to keep a program running. Just let the final answer show as a NaN and keep the programming clear and short. -- -- There are 10 kinds of people: those who understand binary, and those who don't --
Re: Indeterminate forms for the Num type.
Physicist here. One who believes -2**2 is negative. At 23:26 +0800 1/17/06, Audrey Tang wrote: Several options: - - Use whatever the underlying num semantics available That's likely to be in hardware. It might even be hard to detect without looking at the NaN returned and that would be a waste of time. Some formulas can accept a NaN argument and still provide a correct result. At the worst they return a NaN to be tested for later - - Always fail - - Always die Those are non-conforming options See below. - - Specify them to return some definite value. Only on a machine that doesn't do it in hardware or in some special perl function that's unlikely. At this moment, Pugs defines them ad-hocly to: 0/0 == die Illegal division by zero --- wrong. 1/0 should not die either. 0*Inf == NaN --- reasonable but don't re-invent the NaN bit pattern Inf/Inf == NaN --- reasonable but don't re-invent the NaN bit pattern Inf-Inf == NaN --- reasonable but don't re-invent the NaN bit pattern 0**0 == 1 --- Not indeterminate. Answer is correct. Inf**0== 1 --- Not indeterminate. Answer is correct. 1**Inf== 1 --- Not indeterminate. Answer is correct. http://stevehollasch.com/cgindex/coding/ieeefloat.html http://en.wikipedia.org/wiki/Divide_by_zero The IEEE floating-point standard, supported by almost all modern processors, specifies that every floating point arithmetic operation, including division by zero, has a well-defined result. I can't seem to find the actual assigned NaN bit patterns for the above cases, http://docs.sun.com/source/816-2465/iapgCreference.html is helpful but doesn't get there. There may be multiple inf/inf returns in some cases depending on just which inf is involved. There are also NaN's for functions implemented in hardware like atan and exp. -- -- In Christianity, man can have only one wife. This is known as monotony. --
Re: Test Case: Complex Numbers
At 15:59 +0100 11/14/05, Michele Dondi wrote: I must say that I didn't follow the discussion (complex) very much. But this makes me think of this too: the two representations are handy for different calculations. It would be nice if they somehow declared what they can do better (or at all) and have the union take care of which one's methods to use. In another situation, one may implement a system for doing integer arithmetics say in base twelve, and in this case one may have an union to decide to use its .division() method to perform division by three, possibly holding a flag telling that the most accurate status is that held in it. Someday I may become competent to think in perl6 but if we're expanding on the topic. . . Complex numbers are much like 2-D vectors, the real ones and not the ordered lists that are used with hyper operators. A union structure that allows for 3-D vectors some of which are pseudovectors would be interesting. It would also be possible to represent vectors in 3-D spherical coordinates. Oh. . . A pseudovector differs from a vector in that it doesn't change direction when reflected in a plane mirror. The cross product of two ordinary vectors is a pseudovector. So is a magnetic field. As for complex operations which have multiple results I think a principle value approach makes more sense than a list. It's well established for the inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: Perl 6 fears
I fear that, at age 70, I shall not live long enough to become efficient with perl 6. Two full years ago I purchased and read Perl 6 Essentials. That lead me to this list which I have enjoyed but never felt competent to contribute much. Pretty much all of what I leaned in Essentials has been mucked with, or so it seems. I fear that Parrot will not come into widespread use until perl 6 is released. As a rocket scientist, who started before the first FORTRAN compiler was released, I like assembly language and the portability of the Parrot interpreter appeals to me. But perl magic cookies in an assembler? Will it ever fit into a 68HC11? Can it attract the attention of hardware manufacturers? -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: Time::Local
At 13:31 -0400 8/15/05, Mark Reed wrote: More specifically, that's the astronomical Julian Day, or JD, and JD 0 began at noon Universal Time (a.k.a. GMT) on January 1, 4713 BC in the Julian calendar. Sometimes this is called the Julian Astronomical Day, or JAD, to distinguish it from various other misappropriations of the term julian day/date. If anyone gets serious about Julian dates there is also the Modified Julian Date, MJD, used by the US military and others. It differs from the JAD above by a large well-defined integer plus 1/2. The result is a day that begins at midnight and starts at a more recent date that I don't remember. It's not Jan 0, 1970 though. There is also ephemeris time which is the absolute clock that makes Newtonian mechanics come out correctly regardless of changes in the rotational speed of planet Earth. Don't even think about supporting that. -- -- Halloween == Oct 31 == Dec 25 == Christmas --
Re: Comparing rationals/floats
At 16:18 -0700 4/15/05, gcomnz wrote: More questions stemming from cookbook work... Decimal Comparisons: The most common recipe around for comparisons is to use sprintf to cut the decimals to size and then compare strings. Seems ugly. The non-stringification way to do it is usually along the lines of: if (abs($value1 - $value2) abs($value1 * epsilon)) (From Mastering Algorithms with Perl errata) I'm wondering though, if C$value1 == $value2 is always wrong (or almost always wrong) then should it be smarter and: SNIP Marcus Adair I have longed for an OO class that might be called measurement. An object would include a float, a unit of measure, and an estimate of accuracy. Mathematical operations would be overloaded so that the result of a calculation would appropriately handle propagation of the argument's accuracies into the result. It might even do unit conversions but that's another subject. Coercion of a float into a measurement would be automatic with infinite precision assumed. Given the new class it is easy to adjust comparison operators to calculate within experimental error. -- -- Life begins at ovulation. Ladies should endeavor to get every young life fertilized. --
Re: Adding linear interpolation to an array
At 17:53 +0100 3/10/05, Thomas Sandlaß wrote: 'Co' means together like in coproduction. And 'contra' is the opposite as in counterproductive. With instanciating parametric types the question arises how a subtype relation between instanciating types propagates to the template. E.g with Int : Num, covariance would result in Array[Int] : Array[Num]. Referential classes are actually quite difficult because upon write they are contravariant and covariant when read! So a third case of uncomparable types is needed as well, or it is the default if nothing else is specified. A word of caution: Just as in vector operators had their names changed to pacify the mathematicians - thank you - there is a conflict in terms. Covariant and contravariant tensors are the meat of Einstein's formulation of relativity. It all has to do with transformations being in the same direction or the opposite direction as the coordinate differentials. Perhaps there is some similarity. Einstein's presentation is a whole lot easier to understand than the one above. -- -- Marriage and kilo are troubled words. Turmoil results when centuries-old usage is altered in specialized jargon --.
Vector dot Vectoria
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 KE 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 Ithey wanted it to work this way, only that Iothers 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 --
