Re: Commensurability as Key
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.comwrote: 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
Re: Commensurability as Key
One thing to keep in mind is that while adding such things to the Perl 6 core might not be the highest priority at this point something like that could be implemented as a module (if we have a consistent idea what we want). Currently it's possible to change the language to (a subset of) Perl 5 ( https://github.com/rakudo-p5/v5) so it should be possible to at least prototype the units handling. 2013/8/23 Steve Pitchford steve.pitchf...@gmail.com I'll start with your last point: At this point, though, plans to expand on Perl 6's capabilities are taking a back seat to getting Perl 6's existing capabilities implemented. This has been true for some time now, in fact — which is all the more reason to get Perl 6.0 fully implemented as soon as possible. I've been lurking here for a while, and have learned a great deal whilst reading. I've had previous plays with perl 6, would love to again, but find myself limited by freetime. To those ends, I'm just here to chat about something that seems interesting - not to try to influence the hard work being done by all of those pushing the perl6 project forwards. I'm a big fan of Eric Evans Domain Driven design - it's a fantastic book. He pushes the importance of context and relevance with respect to object orientated programming. From that perspective - the answer to the following question is rather brutal: How would you implement, in a robust way, the following things: 1 kg + 1 kg = 2 kg 2 m * 3 m = 6 m^2 5 kg * (3 m/s)^2 = 45 J The answer is that you wouldn't - the problem domain is so vague as to be meaningless. 1kg or 1m of what? Going back to apples - The value of 1kg of apples in terms of representation depends on context. For example, it would be a chore to try to arrange a group of apples to make an exact kilogram. On an individual basis you may have 6 apples. In some cases you may represent that as 6 instances. In another context, you may represent a collection of apples in their tray form - which may have a notional weight with a tolerance. Now, if one were writing a checkout system, it may be sufficient for one to have a fruit class, of which apples and oranges are instances, and both are charged in weight - and their may be additional algorithms to predict stocking levels and re-ordering thresholds, but from personal experience, these algorithms often require the backup of business process such as stock takes to ensure that waste, theft, and approximation errors are taken for granted, and we don't end up with a backlog of rotten apples or empty shelves. That's where software engineering comes in. Systems are sharded and Classes are defined containing aggregations of behaviour. In a grocer, you may never need to add 1kg of apples - you may sell 1.25kg in a single transaction, you could sell 6 apples, depending on your pricing structure. You could even sell 2kg of discounted fruit which includes apples and oranges close to it's use by date. Because you have moved away from primitive arithmetic and into object behaviour and relationship, the notion of 1kg + 1kg becomes irrelevant. Because systems are becoming fragmented, it may make no sense to hook the checkout up directly to the purchase system. You can happily sell weights of apples, but have stock control implemented by how many trays of apples get sent to the shop floor - in this case, you may have an alarm that indicates another tray is probably needed, but it tackles the inherent disjoint between purchase and sale quantities without any complex, over generic modelling of the relationships between trays of apples and weights or other quantities sold on the shopfloor. The fragmentation of the system in this way also allows the canny grocer to flog bags of mixed fruit without worrying that his software developer will charge him thousands and delay implementation of what seems the exploitation of a simple opportunity by a few weeks. -- Forwarded message -- From: Jonathan Lang datawea...@gmail.com Date: Fri, Aug 23, 2013 at 9:47 AM Subject: Re: Commensurability as Key To: Steve Pitchford steve.pitchf...@gmail.com On Aug 23, 2013, at 1:17 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: 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
Re: Commensurability as Key
I have to admit to currently being of the opinion that Commensurability appears to be a feature for program code to perform rather than a programming language to perform, but openly admit to the possibility that I do not understand the concept fully enough for my opinion to be valid. Your point is obviously valid, but regrettably I'm not looking to volunteer. On Fri, Aug 23, 2013 at 12:30 PM, Paweł Murias pawelmur...@gmail.comwrote: One thing to keep in mind is that while adding such things to the Perl 6 core might not be the highest priority at this point something like that could be implemented as a module (if we have a consistent idea what we want). Currently it's possible to change the language to (a subset of) Perl 5 ( https://github.com/rakudo-p5/v5) so it should be possible to at least prototype the units handling. 2013/8/23 Steve Pitchford steve.pitchf...@gmail.com I'll start with your last point: At this point, though, plans to expand on Perl 6's capabilities are taking a back seat to getting Perl 6's existing capabilities implemented. This has been true for some time now, in fact — which is all the more reason to get Perl 6.0 fully implemented as soon as possible. I've been lurking here for a while, and have learned a great deal whilst reading. I've had previous plays with perl 6, would love to again, but find myself limited by freetime. To those ends, I'm just here to chat about something that seems interesting - not to try to influence the hard work being done by all of those pushing the perl6 project forwards. I'm a big fan of Eric Evans Domain Driven design - it's a fantastic book. He pushes the importance of context and relevance with respect to object orientated programming. From that perspective - the answer to the following question is rather brutal: How would you implement, in a robust way, the following things: 1 kg + 1 kg = 2 kg 2 m * 3 m = 6 m^2 5 kg * (3 m/s)^2 = 45 J The answer is that you wouldn't - the problem domain is so vague as to be meaningless. 1kg or 1m of what? Going back to apples - The value of 1kg of apples in terms of representation depends on context. For example, it would be a chore to try to arrange a group of apples to make an exact kilogram. On an individual basis you may have 6 apples. In some cases you may represent that as 6 instances. In another context, you may represent a collection of apples in their tray form - which may have a notional weight with a tolerance. Now, if one were writing a checkout system, it may be sufficient for one to have a fruit class, of which apples and oranges are instances, and both are charged in weight - and their may be additional algorithms to predict stocking levels and re-ordering thresholds, but from personal experience, these algorithms often require the backup of business process such as stock takes to ensure that waste, theft, and approximation errors are taken for granted, and we don't end up with a backlog of rotten apples or empty shelves. That's where software engineering comes in. Systems are sharded and Classes are defined containing aggregations of behaviour. In a grocer, you may never need to add 1kg of apples - you may sell 1.25kg in a single transaction, you could sell 6 apples, depending on your pricing structure. You could even sell 2kg of discounted fruit which includes apples and oranges close to it's use by date. Because you have moved away from primitive arithmetic and into object behaviour and relationship, the notion of 1kg + 1kg becomes irrelevant. Because systems are becoming fragmented, it may make no sense to hook the checkout up directly to the purchase system. You can happily sell weights of apples, but have stock control implemented by how many trays of apples get sent to the shop floor - in this case, you may have an alarm that indicates another tray is probably needed, but it tackles the inherent disjoint between purchase and sale quantities without any complex, over generic modelling of the relationships between trays of apples and weights or other quantities sold on the shopfloor. The fragmentation of the system in this way also allows the canny grocer to flog bags of mixed fruit without worrying that his software developer will charge him thousands and delay implementation of what seems the exploitation of a simple opportunity by a few weeks. -- Forwarded message -- From: Jonathan Lang datawea...@gmail.com Date: Fri, Aug 23, 2013 at 9:47 AM Subject: Re: Commensurability as Key To: Steve Pitchford steve.pitchf...@gmail.com On Aug 23, 2013, at 1:17 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: 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
Re: Commensurability as Key
On Aug 23, 2013, at 2:41 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: How would you implement, in a robust way, the following things: 1 kg + 1 kg = 2 kg 2 m * 3 m = 6 m^2 5 kg * (3 m/s)^2 = 45 J The answer is that you wouldn't - the problem domain is so vague as to be meaningless. 1kg or 1m of what? Understood; but it misses the point I was trying to make. Bringing a measuring system into play needs to be more robust than merely addition and subtraction of common units; it also needs to be able to transform those units into related ones. Let's do a little rocket science: DeltaV = Ve * ln ( m0 / m1 ) Where DeltaV is the total amount your velocity can change, Ve is the velocity of your rocket propellant, m0 is your initial mass, and m1 is your final mass. Simple enough: as long as m0 and m1 are both measured using the same units, they cancel out with each other, letting us take the natural log of a unitless number — which is fortunate, because I don't have a clue how you'd take the logarithm of a number that has units of measure. You then multiply that unitless number by a velocity (measured in units of distance over units of time) to get another velocity (measured in the same units). In this problem, the question of what? is largely irrelevant; the rocket formula will work equally well whether you're shooting a jet of hydrogen out the back of your spacecraft or if you're throwing rocks. Likewise, the number of things that you use as propellant is largely irrelevant. It doesn't hurt to keep track of that information, as long as doing so doesn't interfere with your calculations; but you don't really need it. A related formula is the thrust formula: F = Isp * m' * g0 Where F is the thrust generated, Isp, is the specific impulse of the fuel (a measure of how efficient the fuel is), m' is the mass flow: the rate (measured in mass per unit of time) that the fuel is being expelled, and g0 is the gravitational acceleration at Earth's surface. The reason why g0 is in there is because of a conflation between two very different kinds of units in the early days of rocket science, before metric became the standard in rocketry; namely, pounds (of force) and pounds (of mass). Originally, the formula was simply C F = Isp * m' , with F measured in pounds and m' measured in pounds per second; as such, Isp was assigned units of seconds to make these measurements balance out. When the formula was converted over to metric, it became blatantly obvious that things had been improperly conflated, since force is measured in Newtons and mass flow is measured in kilograms per second. When that's done, it becomes obvious that the Specific Impulse ought to be measured in units of speed (meters per second, in this case) rather than in units of time. But by then, the convention of measuring Specific Impulse in seconds was firmly rooted in the rocket engineering community; so the surface gravity of Earth was brought in as a fudge factor, since that is the ratio of one pound of force to one pound of mass. Going back to apples - The value of 1kg of apples in terms of representation depends on context. For example, it would be a chore to try to arrange a group of apples to make an exact kilogram. On an individual basis you may have 6 apples. In some cases you may represent that as 6 instances. In another context, you may represent a collection of apples in their tray form - which may have a notional weight with a tolerance. Now, if one were writing a checkout system, it may be sufficient for one to have a fruit class, of which apples and oranges are instances, and both are charged in weight - and their may be additional algorithms to predict stocking levels and re-ordering thresholds, but from personal experience, these algorithms often require the backup of business process such as stock takes to ensure that waste, theft, and approximation errors are taken for granted, and we don't end up with a backlog of rotten apples or empty shelves. Some relevant tools: There's a repetition operator infix:xx that's currently set up to take a string and construct a longer one made up of multiple consecutive copies of the original string. e.g., C 5 xx ab eq ababababab . That might be leveraged into a general-purpose assign a count to an object operator: e.g., C 5 xx apple means that you have five apples; C 5 xx kg of apple (would that parse correctly? I'm not sure off the top of my head; but I hope so) means that you have 5 kilograms of apples; and so on. Turning that around, the infix:xx operator could be used to assign a measure (defined by whatever is on the right-hand side) to an otherwise-unitless value (defined by whatever numeric value is on the left-hand side) to get a quantity. You could then do things like multiplying a quantity measured in kg of apple by a quantity measured in dollars / kg of apple to get a quantity
Re: Commensurability as Key
If I understand you correctly, what you are suggesting is the syntactic
sugar similar to perl 5's overload, but with Object/Class support, support
for autoboxing and a way, either by convention or configuration of
facilitating type conversion and degradation?
So one could write something like:
if ( $commuterTrain =~ $bob )
{
print bob caught the train;
}
instead of
if ( $commuterTrain.hasPassenger( $bob ) )
{
print bob caught the train;
}
Might make for a richer method call syntax than .method(...) or -
method(), and produce a cultural convention for method names. It would
also maintain perls reputation for generous use of squiggles.
On Fri, Aug 23, 2013 at 12:53 PM, Jonathan Lang datawea...@gmail.comwrote:
On Aug 23, 2013, at 2:41 AM, Steve Pitchford steve.pitchf...@gmail.com
wrote:
How would you implement, in a robust way, the following things:
1 kg + 1 kg = 2 kg
2 m * 3 m = 6 m^2
5 kg * (3 m/s)^2 = 45 J
The answer is that you wouldn't - the problem domain is so vague as to
be meaningless. 1kg or 1m of what?
Understood; but it misses the point I was trying to make. Bringing a
measuring system into play needs to be more robust than merely addition and
subtraction of common units; it also needs to be able to transform those
units into related ones. Let's do a little rocket science:
DeltaV = Ve * ln ( m0 / m1 )
Where DeltaV is the total amount your velocity can change, Ve is the
velocity of your rocket propellant, m0 is your initial mass, and m1 is your
final mass. Simple enough: as long as m0 and m1 are both measured using
the same units, they cancel out with each other, letting us take the
natural log of a unitless number — which is fortunate, because I don't have
a clue how you'd take the logarithm of a number that has units of measure.
You then multiply that unitless number by a velocity (measured in units of
distance over units of time) to get another velocity (measured in the same
units).
In this problem, the question of what? is largely irrelevant; the rocket
formula will work equally well whether you're shooting a jet of hydrogen
out the back of your spacecraft or if you're throwing rocks. Likewise, the
number of things that you use as propellant is largely irrelevant. It
doesn't hurt to keep track of that information, as long as doing so doesn't
interfere with your calculations; but you don't really need it.
A related formula is the thrust formula:
F = Isp * m' * g0
Where F is the thrust generated, Isp, is the specific impulse of the fuel
(a measure of how efficient the fuel is), m' is the mass flow: the rate
(measured in mass per unit of time) that the fuel is being expelled, and g0
is the gravitational acceleration at Earth's surface. The reason why g0 is
in there is because of a conflation between two very different kinds of
units in the early days of rocket science, before metric became the
standard in rocketry; namely, pounds (of force) and pounds (of mass).
Originally, the formula was simply C F = Isp * m' , with F measured in
pounds and m' measured in pounds per second; as such, Isp was assigned
units of seconds to make these measurements balance out. When the
formula was converted over to metric, it became blatantly obvious that
things had been improperly conflated, since force is measured in Newtons
and mass flow is measured in kilograms per second. When that's done, it
becomes obvious that the Specific Impulse ought to be measured in units of
speed (meters per second, in this case) rather than in units of time. But
by then, the convention of measuring Specific Impulse in seconds was
firmly rooted in the rocket engineering community; so the surface gravity
of Earth was brought in as a fudge factor, since that is the ratio of one
pound of force to one pound of mass.
Going back to apples - The value of 1kg of apples in terms of
representation depends on context.
For example, it would be a chore to try to arrange a group of apples to
make an exact kilogram. On an individual basis you may have 6 apples. In
some cases you may represent that as 6 instances. In another context, you
may represent a collection of apples in their tray form - which may have a
notional weight with a tolerance. Now, if one were writing a checkout
system, it may be sufficient for one to have a fruit class, of which
apples and oranges are instances, and both are charged in weight - and
their may be additional algorithms to predict stocking levels and
re-ordering thresholds, but from personal experience, these algorithms
often require the backup of business process such as stock takes to ensure
that waste, theft, and approximation errors are taken for granted, and we
don't end up with a backlog of rotten apples or empty shelves.
Some relevant tools:
There's a repetition operator infix:xx that's currently set up to take
a string and construct a longer one made up of multiple consecutive copies
of the
Julia: was Re: Commensurability as Key
It is interesting to look at what Julia has done to get numerical performance from a dynamic language http://julialang.org/ and julia's visibility in to the internal representation http://blog.leahhanson.us/julia-introspects.html Regards, Todd Olson
Re: Commensurability as Key
Hello, some clarifications below On 08/21/2013 05:19 AM, Doug McNutt wrote: * a function is a subroutine returning a scalar ( see below) fwiw we don't make that distinction in the specification; we just talk about subroutines. We can return nothing, a scalar or a non-scalar. , 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. And it does, if you teach it to. Perl 6 has some facilities to spread out operations over lists of elements, though not all operations common in linear algebra (vector cross product, multiplying a vector with a matrix etc.) are built-in. Just like they aren't built into Fortran, for that matter. 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. Please don't fall prey to some mismatch in terminology. In Perl 6, a scalar is just some form of container, which happens to be used in variables beginning with a dollar ($). Nothing stops you from putting a vector, however you define or declare one, into a scalar (variable). Nor is there any restriction that makes it impossible to return more than one value from a subroutine -- it just happens to be the case that yary's definition of function restricts functions to one value. But that's really a matter of terminology, not technology. Cheers, Moritz
Re: Commensurability as Key
On Tue, Aug 20, 2013 at 11:19 PM, Doug McNutt dougl...@macnauchtan.comwrote: I confess. I'm here because I hoped perl 6 would do vector operations after reading an early small book. I don't think anyone has said that it won't/can't. Perl 6 indeed returns a scalar... but that scalar may be a container of some kind, including a vector if such a container type has been defined. (Think perl5's refs, only managed automatically instead of making the programmer manually convert between refs and referenced.) Even FORTRAN doesn't actually pass or return arbitrarily sized arrays. It passes pointers around instead; you just can't see them or touch them directly --- but there are ways to *abuse* them, such as the infamous hack that lets you change the value of a literal number because of the representation that has to be used for them just in case they're passed to or returned from a function. Perl6 normally hides this kind of as well, but if for some reason you need to, you can get at the underlying machinery, so the existence of that machinery is admitted instead of being hidden and occasionally coughing up bizarre dust bunnies.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Commensurability as Key
The terms function and relation as used in programming languages have meanings carved out of the pure concepts by the, sometimes, judicious application of Ockham's Chainsaw Massacre in order to get things done. I am speaking of the pure concepts. Procedures are sequences of statements. Statements are state transitions. The before state is the input to the statement viewed as a pure function. The after state is the output of the statement viewed as a pure function. On Tue, Aug 20, 2013 at 10:41 AM, yary not@gmail.com 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, 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? (Also: a ton of apples should _not_, in general, be added to 3000 kg of oranges- unless I operate a refrigerated shipping line, in which case all I care is that they are subclasses of perishables... Adding an acre of orchard to a season in the sun might be less commensurable, though they could both be subclasses of gifts to a lucky winner... hmmm... what was the point again?)
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
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, 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? (Also: a ton of apples should _not_, in general, be added to 3000 kg of oranges- unless I operate a refrigerated shipping line, in which case all I care is that they are subclasses of perishables... Adding an acre of orchard to a season in the sun might be less commensurable, though they could both be subclasses of gifts to a lucky winner... hmmm... what was the point again?)
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: Commensurability as Key
Let's get the basics nailed down and working so that we can learn them, before wandering any further into theoretical CS. On 8/18/13, James Bowery jabow...@gmail.com wrote: Of the two key conceptual gaps in current programming language philosophy -- commensurability and change propagation -- commensurability, if filled with due rigor, has the greatest potential for clearing up confusion by recasting other core features as derivative. Change propagation (eg: properly voiding memoization in lazy functional evaluation aka incremental tabling maintenance in relational evaluation) is something I attempted to address in Perl back in 1999 but was blocked by a bug in recursive use of the tie machinery. However, since that time I've come to the conclusion that as important as change propagation is to put into the core machinery, it isn't nearly as fundamental as is commensurability. Let me introduce commensurability with the seemingly trivial example of units conversion. Units conversion is normally tacked on as an after-thought in programming languages. (Digression: One programming language that had units built into the compiler was the PLATO system's TUTOR programming language -- a generally nasty language which I encountered while programming Spasimhttp://en.wikipedia.org/wiki/Spasim -- that, nevertheless, pioneered some interesting concepts due to the relative lack of precedent in programming languages targeting ordinary people like teachers.) However, while doing real world calculations, correct handling of units via automatic conversion is, in fact, more important than type checking. Underlying units checking (and conversion) is commensurability. For example, apples are not, in general, commensurable with oranges: a ton of apples should _not_, in general, be added to 3000 kg of oranges -- although adding a ton of apples to 3000kg of apples makes sense as we are dealing with commensurable quantities although in differing units. Moreover, by incorporating dimensional analysis into the arithmetic machinery, not only can units conversion be automated, but arithmetic expressions themselves can frequently be automatically inferred from the inputs provided along with the units of the output demanded (see the semicolon ';' operator of the Calchemy units calculatorhttp://www.testardi.com/rich/calchemy2/ ). While well-designed type machinery, based on things like assertions and coercions, can be adapted to implement automatic units conversion (hence checking), that is getting the cart before the horse. Here's why: If we accept the idea that the higher level of expression we allow the programmer, the better (as it leads to more disciplined separation of 'how' pragmas from 'what' specification during the authoring process) then we should recognize that relational expression should be core since functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. If we have relational expression as core, commensurability, hence units handling, falls out of what Bertrand Russell called relation arithmetic in Principia Mathematic volume IV. The most advanced work in applying relation arithmetic to programming language design was done by the late Tom Etter while at Paul Allen's thinktank Interval Research, with Tom's follow-on work at HP funded under my (very limited) authority there. Tom's paper, Relation Arithmetic Revivedhttp://www.boundaryinstitute.org/bi/articles/Relation-arithmetic_Revived_v3.pdf documents Russell's conflation of relational similarity with relational congruence as the mistake that blocked practical application of relation arithmetic in Codd's work on relational algebra -- hence things like the object relational impedance mismatch. However, if we look deeper into what was going on, we find that the very idea of sets -- hence the normal notion of data types -- is similarly ill founded, as we can, and should, bootstrap set theory from a more fundamental theory of relative (or relational) identityhttp://www.boundaryinstitute.org/bi/articles/Three-place_Identity.pdf . Just how far do the implications of this go? Well, for starters, the core laws of quantum mechanics fall out as completely general theorems of relation arithmetic generalized to include negative relationships (opt cit). Among the implications of this are core programming language constructs for quantum information systems. Sorry if this throws a monkey-wrench at, if not into, the works -- but the Perl culture is one of the few places that is has the philosophical equipment to take such a lofty concept as commensurability and commit just enough Ockham's Chainsaw Massacre to retain much of its value in practical programming systems.
Re: Commensurability as Key
Maybe Perl 7. On Mon, Aug 19, 2013 at 2:30 PM, Parrot Raiser 1parr...@gmail.com wrote: Let's get the basics nailed down and working so that we can learn them, before wandering any further into theoretical CS. On 8/18/13, James Bowery jabow...@gmail.com wrote: Of the two key conceptual gaps in current programming language philosophy -- commensurability and change propagation -- commensurability, if filled with due rigor, has the greatest potential for clearing up confusion by recasting other core features as derivative. Change propagation (eg: properly voiding memoization in lazy functional evaluation aka incremental tabling maintenance in relational evaluation) is something I attempted to address in Perl back in 1999 but was blocked by a bug in recursive use of the tie machinery. However, since that time I've come to the conclusion that as important as change propagation is to put into the core machinery, it isn't nearly as fundamental as is commensurability. Let me introduce commensurability with the seemingly trivial example of units conversion. Units conversion is normally tacked on as an after-thought in programming languages. (Digression: One programming language that had units built into the compiler was the PLATO system's TUTOR programming language -- a generally nasty language which I encountered while programming Spasimhttp://en.wikipedia.org/wiki/Spasim -- that, nevertheless, pioneered some interesting concepts due to the relative lack of precedent in programming languages targeting ordinary people like teachers.) However, while doing real world calculations, correct handling of units via automatic conversion is, in fact, more important than type checking. Underlying units checking (and conversion) is commensurability. For example, apples are not, in general, commensurable with oranges: a ton of apples should _not_, in general, be added to 3000 kg of oranges -- although adding a ton of apples to 3000kg of apples makes sense as we are dealing with commensurable quantities although in differing units. Moreover, by incorporating dimensional analysis into the arithmetic machinery, not only can units conversion be automated, but arithmetic expressions themselves can frequently be automatically inferred from the inputs provided along with the units of the output demanded (see the semicolon ';' operator of the Calchemy units calculatorhttp://www.testardi.com/rich/calchemy2/ ). While well-designed type machinery, based on things like assertions and coercions, can be adapted to implement automatic units conversion (hence checking), that is getting the cart before the horse. Here's why: If we accept the idea that the higher level of expression we allow the programmer, the better (as it leads to more disciplined separation of 'how' pragmas from 'what' specification during the authoring process) then we should recognize that relational expression should be core since functions are (sugarably) degenerate (many to 1) relations and procedures are (sugarably) degenerate (state-transition) functions. If we have relational expression as core, commensurability, hence units handling, falls out of what Bertrand Russell called relation arithmetic in Principia Mathematic volume IV. The most advanced work in applying relation arithmetic to programming language design was done by the late Tom Etter while at Paul Allen's thinktank Interval Research, with Tom's follow-on work at HP funded under my (very limited) authority there. Tom's paper, Relation Arithmetic Revived http://www.boundaryinstitute.org/bi/articles/Relation-arithmetic_Revived_v3.pdf documents Russell's conflation of relational similarity with relational congruence as the mistake that blocked practical application of relation arithmetic in Codd's work on relational algebra -- hence things like the object relational impedance mismatch. However, if we look deeper into what was going on, we find that the very idea of sets -- hence the normal notion of data types -- is similarly ill founded, as we can, and should, bootstrap set theory from a more fundamental theory of relative (or relational) identity http://www.boundaryinstitute.org/bi/articles/Three-place_Identity.pdf . Just how far do the implications of this go? Well, for starters, the core laws of quantum mechanics fall out as completely general theorems of relation arithmetic generalized to include negative relationships (opt cit). Among the implications of this are core programming language constructs for quantum information systems. Sorry if this throws a monkey-wrench at, if not into, the works -- but the Perl culture is one of the few places that is has the philosophical equipment to take such a lofty concept as commensurability and commit just enough Ockham's Chainsaw Massacre to retain much of its value in
