Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-07 Thread TSa

HaloO,

John M. Dlugosz wrote:
When I mentioned this before, there was big flack over mentioning the 
way C++ did it.  I think that must have been miscommunicated, since I 
wasn't even talking about summing all the arguments when he brought up 
Manhattan dispatch.


That he there being me, I just want to record that I referred to the
metric MMD discussion because you argued in favor of a way to balance
rw with specificity of the input value. The spec currently speaks of
type narrowness without defining that rigorously. My plea is for
:(Int $x) and :(Int $x is rw) to be indistinguishable and thus
unsuitable in the same multi. Furthermore I think that :(Num $x)
and :(Int $x is rw) are distinguishable overloads as far as the
input value is concerned but a user might be surprised that a call
with a literal 3 fails where one with 3.1 doesn't or that 3.1 in
a container is handled as 3 because of the rw. This would violate
the principle of least surprise.

BTW, what is a flack?

Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int ), (int), (const int *),
(const int ), (const int), (int * const) and (const int * const)?
I'm too lazy to look up the details, sorry.

Regards, TSa.
--

The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-07 Thread Austin Hastings

TSa wrote:



BTW, what is a flack?


See http://en.wikipedia.org/wiki/Flak_%28disambiguation%29


Originally, (FL)ug(a)bwehr (K)anone -- German 88mm anti-aircraft cannon 
of WWII.


Subsequently, any anti-air gun or cannon, particularly when fired at a 
position rather than aimed at a particular target.


Presently:  [[ oproer, samenscholing, Tumult, schiamazzo ]]

Criticism, ado, alarm, excitement, noise, grief, hullabaloo, angst, 
wailing and gnashing of teeth, din, clamor, hubbub, rumpus, tumult, 
uproar, disturbance, objection, consternation, meshugas, narrichkeit, 
shemozzle, furor.


=Austin




Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-07 Thread Brandon S. Allbery KF8NH


On 2008 May 7, at 4:21, TSa wrote:


BTW, what is a flack?


He's using flak (shrapnel; usual usage catching flak over ...)  
without understanding it.



Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int ), (int), (const int *),
(const int ), (const int), (int * const) and (const int * const)?
I'm too lazy to look up the details, sorry.


Been a long time, but I thought C++ compilers threw up their arms in  
despair if multiple conversion paths of the same length existed (that  
is, it could use (D)(B)A or (D)(C)A).  That said, (int ) and (const  
int) are identical to (int) for dispatch purposes[*] and (int *) is a  
completely different type which could only be used if something  
provided a conversion for it, which would be unusual.


[*] The const modifier corresponds to is ro and the  is like  
aliasing a name with :=, in Perl6 terms; neither is actually part of  
the type.  That said, const can be used as a constraint (like a  
Perl6 subset type; not sure about .  But note that C++ has been  
updated several times since I last looked, and I may well be  
misremembering even the old standard.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH




Re: Where is Manhattan Dispatch discussion?

2008-05-06 Thread Ovid
--- John M. Dlugosz [EMAIL PROTECTED] wrote:

 I want to review and collect the wisdom of what has been discussed
 before.  Someone mentioned this the other day, as being a significant
 consensus.  But I can't find anything in the forum archives.
 
 Can someone point to the discussion, position papers, etc.?  

This this:

  http://use.perl.org/~luqui/journal/27362

Luke makes some interesting comments, but you'll want to click the
Great Multimethod Debate link (http://tinyurl.com/5hm4ze).

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/


Re: Where is Manhattan Dispatch discussion?

2008-05-06 Thread John M. Dlugosz
I'm still in the dark... I find an positions for manhattan distance 
but no definition of what that is.  I did find the alternative pod page 
earlier.


--John

Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:

--- John M. Dlugosz [EMAIL PROTECTED] wrote:

  

I want to review and collect the wisdom of what has been discussed
before.  Someone mentioned this the other day, as being a significant
consensus.  But I can't find anything in the forum archives.

Can someone point to the discussion, position papers, etc.?  



This this:

  http://use.perl.org/~luqui/journal/27362

Luke makes some interesting comments, but you'll want to click the
Great Multimethod Debate link (http://tinyurl.com/5hm4ze).

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

  




Re: Where is Manhattan Dispatch discussion?

2008-05-06 Thread Carl Mäsak
John ():
 I'm still in the dark... I find an positions for manhattan distance but no
 definition of what that is.  I did find the alternative pod page earlier.

I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is so-called L1 distance, i.e.
Pythagoras' distance summation formula but without all the squaring
and surding.

 http://en.wikipedia.org/wiki/Taxicab_geometry

I imagine the concept is applied to parameter types in the discussion
in question.

// Carl


Re: Where is Manhattan Dispatch discussion?

2008-05-06 Thread Mark A. Biggar

Carl Mäsak wrote:

John ():

I'm still in the dark... I find an positions for manhattan distance but no
definition of what that is.  I did find the alternative pod page earlier.


I don't have a whole answer for you, but a part that may help. What is
generally meant by Manhattan distance is so-called L1 distance, i.e.
Pythagoras' distance summation formula but without all the squaring
and surding.

 http://en.wikipedia.org/wiki/Taxicab_geometry

I imagine the concept is applied to parameter types in the discussion
in question.


To do multi method dispatch, you want to select the method that best 
matches the parameters in the call. One way to do that is to define a 
measure for distances between types and they use the method that's at 
the minimum distance.  One simple measure is that a type is distance 0 
from itself and distance 1 from it's immediate super-types, distance 2 
from the immediate super-types of it's immediate super-types, etc. When 
dispatching over a single parameter picking the method at the minimum 
distance is the usual most specific type match. But when you want to do 
multi-method dispatch, you need some rule to combine the various 
distances of the individual parameters into a single measure value, then 
pick the method at the minimum distance by that combined measure. 
Manhattan Distance or Taxicab Distance is the rule that the combined 
distance is just the simple unweighted sum of the individual parameter 
distances. The is named after the fact that a taxi must follow the 
streets and to go 3 block north and 4 blocks west it must travel 7 
blocks not the 5 blocks of the euclidean distance.


BTW, if you want to do euclidean distance comparisons you don't need to 
do any square roots. Square root is monotonic, so order relations 
between the sums of squares values is the the same whether you take 
square roots or not.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]



Re: Where is Manhattan Dispatch discussion?

2008-05-06 Thread TSa

HaloO,

Mark A. Biggar wrote:
To do multi method dispatch, you want to select the method that best 
matches the parameters in the call.


The fundamental flaw of metric mmd is that it trades degrees of
specificity. Consider the subtype chain E : D : C : B : A
where the rule is that having an E it is better handled by a
method dealing with a D than one dealing with an A. The same
is the case for having a D being better handled by a C than an
A method. Now consider a multi with the two signatures :(A,C,C)
and :(D,A,A) and a call with (E,D,D) that goes to :(D,A,A) since
7  8. But note that it handles the two Ds as As instead of Cs
as in single dispatch.

Dispatch has to go to the single most capable implementation
*not* to the least misfit! The call above has to be brought
to the attention of a programmer.


Regards, TSa.
--

The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan


Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread John M. Dlugosz

Mark A. Biggar mark-at-biggar.org |Perl 6| wrote:


To do multi method dispatch, you want to select the method that best 
matches the parameters in the call. One way to do that is to define a 
measure for distances between types and they use the method that's at 
the minimum distance.  One simple measure is that a type is distance 0 
from itself and distance 1 from it's immediate super-types, distance 2 
from the immediate super-types of it's immediate super-types, etc. 
When dispatching over a single parameter picking the method at the 
minimum distance is the usual most specific type match. But when you 
want to do multi-method dispatch, you need some rule to combine the 
various distances of the individual parameters into a single measure 
value, then pick the method at the minimum distance by that combined 
measure. Manhattan Distance or Taxicab Distance is the rule that 
the combined distance is just the simple unweighted sum of the 
individual parameter distances. The is named after the fact that a 
taxi must follow the streets and to go 3 block north and 4 blocks west 
it must travel 7 blocks not the 5 blocks of the euclidean distance.



OK, so basically the fit is the sum of the fits of all the parameters.  
If form A has a distance of 2 for the first argument and 5 for the 
second, and form B has a distance of 0 for the first and 10 for the 
second, form A is better.


I heard this term come up the other day with respect to matching value 
types =and= other attributes such as rw or ref-ness.  I thought he meant 
that these were different directions like streets and avenues, of one 
parameter.


I have problems with a simple sum.  The distance is artificially 
inflated if you make lots of small derivation steps vs one large 
change.  The concept of derivation steps is ill-defined for 
parameterized types and types that change virtual type names during 
derivation so there is no subtype relationship.


In C++, which must be resolved at compile time, the overloading 
resolution mechanism demands that =every= parameter be at least as good 
of a match, and one strictly better match.  So the implementation never 
guesses if worse-left/better-right is a better fit than 
better-left/worse-right.  However, you are assured that everything is 
brought to your attention at program build time, before run time, so 
complaining is not as serious as a run-time error where you might prefer 
DWIM.


--John


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread TSa

HaloO,

John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading 
resolution mechanism demands that =every= parameter be at least as good 
of a match, and one strictly better match.  So the implementation never 
guesses if worse-left/better-right is a better fit than 
better-left/worse-right.  However, you are assured that everything is 
brought to your attention at program build time, before run time, so 
complaining is not as serious as a run-time error where you might prefer 
DWIM.


Perl 6 is the same, just at runtime with actual types of actual objects.
That's it.

Regards, TSa.
--

The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread chromatic
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:

 I have problems with a simple sum.  The distance is artificially
 inflated if you make lots of small derivation steps vs one large
 change.  The concept of derivation steps is ill-defined for
 parameterized types and types that change virtual type names during
 derivation so there is no subtype relationship.

Those are precisely my objections.  I'm not a fan of derivation in general, 
but I've never understood how changing MMD resolution based on degree of 
derivation didn't break Liskov.  (Damian tried to explain it to me at least 
once, but he's smarter than I am and I didn't get it.)

-- c


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread Larry Wall
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
 HaloO,

 John M. Dlugosz wrote:
 In C++, which must be resolved at compile time, the overloading resolution 
 mechanism demands that =every= parameter be at least as good of a match, 
 and one strictly better match.  So the implementation never guesses if 
 worse-left/better-right is a better fit than better-left/worse-right.  
 However, you are assured that everything is brought to your attention at 
 program build time, before run time, so complaining is not as serious as a 
 run-time error where you might prefer DWIM.

 Perl 6 is the same, just at runtime with actual types of actual objects.
 That's it.

Indeed, Perl 6 threw out Manhattan distance a couple years ago.  Do we
have to spec everything that Perl 6 ever was but isn't now?  :)

Larry


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:

HaloO,

John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading 
resolution mechanism demands that =every= parameter be at least as 
good of a match, and one strictly better match.  So the 
implementation never guesses if worse-left/better-right is a better 
fit than better-left/worse-right.  However, you are assured that 
everything is brought to your attention at program build time, before 
run time, so complaining is not as serious as a run-time error where 
you might prefer DWIM.


Perl 6 is the same, just at runtime with actual types of actual objects.
That's it.

Regards, TSa.
Then why is everyone against no worse for all parameters, rather than 
summing?


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread John M. Dlugosz

Larry Wall larry-at-wall.org |Perl 6| wrote:

On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
  

HaloO,

John M. Dlugosz wrote:

In C++, which must be resolved at compile time, the overloading resolution 
mechanism demands that =every= parameter be at least as good of a match, 
and one strictly better match.  So the implementation never guesses if 
worse-left/better-right is a better fit than better-left/worse-right.  
However, you are assured that everything is brought to your attention at 
program build time, before run time, so complaining is not as serious as a 
run-time error where you might prefer DWIM.
  

Perl 6 is the same, just at runtime with actual types of actual objects.
That's it.



Indeed, Perl 6 threw out Manhattan distance a couple years ago.  Do we
have to spec everything that Perl 6 ever was but isn't now?  :)

Larry

  
No, just point me to what it says now.  Or the scraps so I can collect 
them together and say it during my productive period.


When I mentioned this before, there was big flack over mentioning the 
way C++ did it.  I think that must have been miscommunicated, since I 
wasn't even talking about summing all the arguments when he brought up 
Manhattan dispatch.


Re: Minimal Distance (Re: Where is Manhattan Dispatch discussion?)

2008-05-06 Thread Larry Wall
On Tue, May 06, 2008 at 08:47:47PM -0500, John M. Dlugosz wrote:
 Larry Wall larry-at-wall.org |Perl 6| wrote:
 On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
   
 HaloO,

 John M. Dlugosz wrote:
 
 In C++, which must be resolved at compile time, the overloading 
 resolution mechanism demands that =every= parameter be at least as good 
 of a match, and one strictly better match.  So the implementation never 
 guesses if worse-left/better-right is a better fit than 
 better-left/worse-right.  However, you are assured that everything is 
 brought to your attention at program build time, before run time, so 
 complaining is not as serious as a run-time error where you might prefer 
 DWIM.
   
 Perl 6 is the same, just at runtime with actual types of actual objects.
 That's it.
 

 Indeed, Perl 6 threw out Manhattan distance a couple years ago.  Do we
 have to spec everything that Perl 6 ever was but isn't now?  :)

 Larry

   
 No, just point me to what it says now.  Or the scraps so I can collect them 
 together and say it during my productive period.

See S12, Multisubs and Multimethods, around where it says:

A candidate is considered narrower than another candidate if at least
one of its parameters is narrower and all the rest of its parameters
are either narrower or tied.  This defines the partial ordering of
all the candidates.

Larry