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.
Putting tools like PHP and VB to one side for a second, Maybe I'm getting the wrong end of the stick, but this just seems like a case of what is known in object orientated terms as "Primitive Obsession" - in this case, the overuse of integer and float arithmetic where objects make far better use cases. There does seem to be significant clear water between the use of procedural/functional languages for Maths and the rising trend of using OO languages ( though all too often badly ) for implementing industrial solutions - does this represent a split between computer science and software engineering? OO - done right - emphasises relationships and the strengths of type over traditional, potentially clumsier coding. This is obviously not without overhead, and does appear to be a paradigm shift too far for many, but I'm wondering if anyone can explain to me why OO is not the most appropriate solution to the "Commensurable" problem space in perl 6? Steve On Thu, Aug 22, 2013 at 5:54 AM, Doug McNutt <dougl...@macnauchtan.com>wrote: > 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++ >
