Re: Ev2 using move-away and move-here

Branko Čibej wrote:
On 14 Aug 2013 16:23, "Julian Foad" <julianfoad_at_btopenworld.com> wrote:
>> > and also makes validating the drive easier.
>>
>> I'm not sure what you're thinking about validating the editor drive being easier.
>
> Move away without a matching moved here (or the converse) is clearly invalid.
> It must be trivial for the receiver to detect that. Making the temporary
> locations explicit makes that so much easier.

It does?  I don't see how.  You're saying that keeping track of whether there are mismatches in a sequence such as this (which swaps siblings A and B):

  - move(A,tmp1)
  - move(B,A)
  - move(tmp1,B)

is so much easier than with a corresponding non-explicit sequence which could be

  - move(A,tmp1)
  - move(B,tmp2)
  - move(tmp2,A)

  - move(tmp1,B)

or

  - move(A,tmp1)
  - move(B,tmp2)  - move(tmp1,B)
  - move(tmp2,A)

?  Assuming an implementation whereby the receiver keep a list of nodes that are currently in temporary storage, I can see that the list will be shorter with the former protocol, and have fewer insertions and deletions, but that's all.

> Regarding direct move without intermediate state, IMO the driver should be
> required to to use that whenever it can.

That would necessitate us defining "whenever it can" algorithmically.  For example, calculating the minimum possible number of direct moves required to perform a given set of moves.  That seems difficult.  Granted the Ev2 design philosophy includes being minimal (no duplications) in general... but I just don't see this particular rule being easy to codify.  Perhaps we can do it.

> Driver always has enough info to know that receiver can process such a move. If
> it cannot, that indicates a bug in the driver.

Yup, agreed there.

- Julian
Received on 2013-08-15 15:31:02 CEST