On Wed, 2009-09-02 at 12:04 -0400, Aubrey Jaffer wrote:
> | From: Vincent Manis <[email protected]>
> | Date: Tue, 1 Sep 2009 17:14:21 -0700
> |
> | I was thinking about what metrics one *might* use on Scheme
> | implementations. This was happening during my fitness class this
> | morning, so we're not exactly talking profound thinking.
> | Nonetheless, I came up with the following list.
> |
> | ...
> |
> | I have no doubt omitted your favorite criterion, and for that you
> | are of course free to flame me. However, my point is really the
> | obvious one, namely that no single figure of merit makes any sense.
There are restricted cases in which the likelihood of success in
a particular endeavor can be related fairly strongly to a single
number.
For purposes of porting scheme programs from one implementation
to another, I think you could get a good idea of the probability
of success with a distance metric between the two implementations
involved.
It might look like this:
Forall n in the set of semantically significant forms defined
in the source implementation (including syntax,
procedures, "magic" variables, extended constant
syntax, "infix hacks", etc)
# I(n) = probabiity that feature incompatibility on a form in
the source implementation will break a port of a
program which works in that implementation.
I(n) = proportion ( 0..1 ) of programs that use form n.
# J(n) = probability of breakage of porting due to differences
in a particular feature between source and target
implementations.
J(n) = 0 if form n (in fully compatible form) is
available in the target implementation,
J(n) = I(n) otherwise.
# K(n) = probability of program compatibility w/r/t each feature
K(n) = 1 - I(n)
# P = total chances of compatibility when moving a "typical"
program from source to target implementation.
P(source, target) = the Product of terms I(n) for all n.
I think I could claim (although I'd want to look at my stats book
pretty closely first) that the probability of a given program that
runs on the source implementation S running without modification on
the target implementation T, given typical distributions of use of
features found in the source implementation, is P(S,T). If it isn't,
it's because I made a mistake in the statistical relationships
given above.
Suppose I have a program and it runs on implementation S, and I'm
looking for an implementation T that I can port it to. I could do
worse than starting by looking in a (hypothetical) table that gave
P(S,T) for S and T being members of the set of scheme implementations
and picking T such that P(S,T) is maximal.
A table like that would certainly be useful, as would the
corresponding list of such potentially compatibility-breaking
features. I think that P(S,T) for all T is an important part of
the measure of "goodness" for implementation S, and likewise, that
P(S,T) for all S is an important part of the measure of goodness
for an implementation T.
But this is not any kind of ordered relationship. This is a
measure of pairwise compatibility among implementations, and
it's not even symmetric. It's something like a good starting
point for cluster analysis, but that's about it. And even as
a distance or compatibility metric, it's still only one measure
out of many as to whether a particular implementation is really
"good."
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
