[EM] Markus, 19 May, '05, 0114

[MIKE OSSIPOFF]

Markus--

You say:

Well, although you have been pointed to this error dozens of
times in the last 5 years and although you have admitted this
error several times, you keep on using this error as an argument.

I reply:

I have no idea what you mean by that. I've admitted that error several times 
during the past day or two. I don't know what it means to say that I use it 
as an "argument", but yes I use it as an explanation for the quotes that you 
repeatedly link to, from about 5 years ago.

You continue:

Russ Paielli immediately stopped claiming
that he had invented RAV. Russ Paielli didn't say something like:
"I hadn't read Kevin's proposal when I proposed RAV. Therefore,
I can rightly claim that I invented RAV."

I reply:

After you posted that you'd introduced CSSD to EM, I stopped calling CSSD my 
own suggestion. I'd come up with CSSD during the Debian discussion, when 
Norm criticized SSD for its lack of clone independence in small committees. 
I posted CSSD to EM, believing that it was my proposal. You pointed out that 
you'd previously posted it, and I stopped calling CSSD my own proposal.

My version of CSSD stopped when there are no cycles in the Schwartz set. 
Yours stopped when there are no defeats in the Schwartz set. Same thing, but 
"no defeats" seemed neater than "no cycles", and so at that time I changed 
my CSSD stopping rule to "no defeats in the Schwartz set".

But you never posted SSD to EM. Yes, I devised CSSD. But you devised it 
before I did, and when I found that out, I no longer claimed credit for 
CSSD. But you didn't post SSD. CSSD is not SSD.

You continue:

On the other side, you keep on using your claim, that you hadn't
completely understood the Schulze method when you proposed SSD,
as an argument to claim that you "devised" SSD.

I reply:

Not only did I devise SSD, but I devised CSSD. But you had devised CSSD 
before I did. When I found that out, I acknowledged it and no longer claimed 
credit for CSSD.

Yes, Steve and I had never heard of CSSD at the time that we devised SSD, so 
we didn't devise SSD as a variation of CSSD, but rather "from scratch". In 
any case, CSSD is not SSD. SSD is more publicly proposable.

You continue:

By the way: Already in 2001, Norman Petry complained that you try to
take credit for this method. He wrote (6 Feb 2001):

    Regardless of what names we use when referring to these methods during
our committee discussions, I think it is appropriate that if one of
these variants is recommended to Debian that it be named SCHULZE'S
METHOD.  This is because:

1. Schulze, version 1: The 'Beat-Or-Tie-path' method was first proposed by
Markus Schulze on Sat, 4 Oct 1997 (see EM Archives, "Re: Condorect sub-cycle
rule").


I reply:

The Beat-Or-Tie-Path method is not BeatpathWinner, and is not equivalent to 
CSSD.

You continue, quoting Norm:

Unfortunately, eGroups has not archived this message, but it can
    be found at Rob's site, in this text file (but mistakenly referred to 
there
as "Tideman's Method"): http://www.eskimo.com/~robla/em/archive/em.97q4

2. Schulze, version 2: The 'Schwartz Sequential Dropping' (SSD) method was
first proposed by Markus Schulze on Mon, 10 Aug 1998.  His description can
be found here:
http://groups.yahoo.com/group/election-methods-list/message/673


I reply:

That is not a description of SSD. SSD stops when there is a candidate with 
no pairwise defeats. Your method there stops when there is only one 
"potential winner". But you don't say what "potential winner" means. What if 
there are two unbeaten candidates in a pair-tie? By your defintion, the 
procedure doesn't stop. Your definition is not a definition of SSD, except 
when you supply things that it doesn't say.

[...]

    4. Beatpath Winner: This was not specifically proposed by Markus 
Schulze,


I reply:

Correct. Originally you were saying that Schulze's method was 
Beat-And-Tie-Path-Winner.
Then later you defined Schulze's method as an umbrella class of methods that 
includes Beat-And-Tie-Path-Winner and BeatpathWinner, and other methods too.

I'd said:

    I don't save e-mail back to those days. But my mention of SSD on EM is
in the EM archives. That's really all you need.


You say:

Well, the very first time that the term "Schwartz Sequential Dropping"
(SSD) was being used was on 18 Feb 2000 in a mail by you. In that mail,
you wrote that "SSD is equivalent to Schulze's method".

I reply:

I coined "BeatpathWinner" to name the method that I still call by that name. 
I mistakenly believed that that was what "Schulze's method" means. Later, 
I've repeatedly admitted that Schulze's method does not mean BeatpathWinner. 
And I said that SSD is equivalent to BeatpathWinner, because they're 
equivalent when there are no pairwise ties. That was sloppy of me, though 
it's true in public elections. I've repeatedly admitted that it was 
incorrect to say that SSD is equivalent to BeatpathWinner. CSSD is 
equivalent to BeatpathWinner. SSD isn't equivalent to BeatpathWinner, though 
in public elections, where there are no pairwise ties, they amount to the 
same thing.

You continue:

Actually, the
fact that "SSD is equivalent to Schulze's method" was your main argument
for proposing SSD.

I reply:

I coined "BeatpathWinner" to name the method that I still call by that name. 
At that time I mistakenly believed that Schulze's method meant 
BeatpathWinner. I said that SSD was equivalent to  BeatpathWinner because 
they're equivalent when there are no pairwise ties. That was admittedly 
sloppy, and I've corrected that error many times during the last few days. I 
suggest that you read what you're replying to, and then it won't be 
necessary to repeat things for you so many times.

But it's ridiculous to say that that was my main argument for proposing SSD. 
I justified, and still do justify, SSD because of its advantages, which I've 
named in recent e-mails.

You continue:

Therefore, the EM archives don't support your claim
that "SSD is an Eppley-Ossipoff method".

I reply:

The definition of yours that you link to and claim as an SSD definition is 
not an SSD definition.

I'd said:

    You ask why I decided to promote SSD. Because it's clone-independent
in public elections, and because it meets SFC, GSFC, WDSC, and SDSC.


You say:

Nope. You didn't consider independence of clones important when you
proposed SSD. Nor did you mention clones in that mail.

I reply:

I considered clone-independence important as soon as I heard of it. In fact, 
before I'd heard of "clone sets", I'd defined "co-partisan sets", with the 
same meaning. I used Copeland's great dependence on co-partisan sets as an 
argument against Copeland.

No, I didn't consider clone-independence so important that I rejected PC. Or 
Approval, which fails my ICC, but passes the one that you posted. But I 
nevertheless considered ICC important.

Whether I mentioned clone-independence in some particular e-mail, I have no 
idea.

I'd said:

    But I consider the merit differences between RP and SSD completely
negligible in public elections. That's where Steve and I disagree.
What's wrong with disagreeing?


You want to know what's wrong with that? Well, on the one side
you claim that you are having quite productive discussions with
other people off-list.

I reply:

At this time I'm not discussing offlist.  I claim that at times I have, 
however had very productive offlist discussions.
.
You continue:

And on the other side, you neither forward
nor save such discussions.

I reply:

I save my e-mail for a long time. But not that long.

You continue:


Do you have some kind of politics
like "discuss in a constructive manner only off-list"?

I reply:

Excluding you from that discussion was Norm's suggestion, not mine.

At the time that SSD was devised, and when Steve proposed the BeatpathWinner 
Criterion, I wasn't on the list.

I then rejoined the list to report SSD, and to post my classification of 
Condorcet versions.

Mike Ossipoff

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/