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
Fwd: Commensurability as Key
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 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
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
