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++
