-
Notifications
You must be signed in to change notification settings - Fork 3
/
1108
118 lines (90 loc) · 4.48 KB
/
1108
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
From - Wed May 17 14:55:20 2000
Return-Path: <[email protected]>
Received: from gecko.serc.rmit.edu.au ([131.170.42.16])
by mx9.mindspring.com (Mindspring Mail Service) with ESMTP id shuqeu.hsj.37kbi17
for <[email protected]>; Sun, 14 May 2000 23:07:09 -0400 (EDT)
Received: (from majordomo@localhost)
by gecko.serc.rmit.edu.au (8.8.5/8.8.5) id CAA26882
for agora-discussion-list; Mon, 15 May 2000 02:58:05 GMT
Received: from fw.serc.rmit.edu.au (fw-in.serc.rmit.edu.au [131.170.42.1])
by gecko.serc.rmit.edu.au (8.8.5/8.8.5) with ESMTP id CAA26879
for <[email protected]>; Mon, 15 May 2000 02:58:03 GMT
Received: (from mail@localhost)
by fw.serc.rmit.edu.au (8.9.3/8.9.1) id NAA50001
for <[email protected]>; Mon, 15 May 2000 13:19:57 +1000 (EST)
Received: from silas-2.cc.monash.edu.au(130.194.1.7) by fw.serc.rmit.edu.au via smap (V2.1)
id xma049997; Mon, 15 May 00 13:19:40 +1000
Received: (from gardner@localhost)
by silas-2.cc.monash.edu.au (8.9.1a/8.9.1) id NAA28716
for [email protected]; Mon, 15 May 2000 13:03:17 +1000 (EST)
From: Steve Gardner <[email protected]>
Message-Id: <[email protected]>
Subject: DIS: Repost of CFJ 1108
To: [email protected] (Agora Nomic Discussion List)
Date: Mon, 15 May 2000 13:03:17 +1000 (EST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: bulk
Reply-To: [email protected]
X-Mozilla-Status: 8001
X-Mozilla-Status2: 00000000
X-UIDL: shuqeu.hsj.37kbi17
==========================================================================
CFJ 1108
The requirement to "execute a Payment Order for 0 VTs" can be fulfilled
by doing nothing.
==========================================================================
Judge: Morendil
Judgement: TRUE
Eligible: Antimatter, Blob, Crito, Chuck, General Chaos, Harlequin,
Macross, Michael, Morendil, Oerjan, Steve
Not eligible:
Caller: Kolja A.
Barred: lee, Murphy, Proglet
Disqualified: -
On Hold: elJefe
======================================================================
History:
Called by Kolja A.: Tue, 20 Oct 1998 12:11:23 +0200
Assigned to Morendil: Wed, 21 Oct 1998 10:37:51 +1000
Morendil Judges TRUE: Wed, 21 Oct 1998 11:15:07 +0200
Judgement published: Wed, 21 Oct 1998 22:36:01 +1000
======================================================================
Caller's Arguments:
The POs that are defined and referred to in the rules are, by
definition, POs for positive multiples of a currency's MUQ (R1596).
Therefore, a "PO for 0 VTs" is an object not defined by the rules, and
so is the action of executing one.
Therefore the player who is required to "execute the PO" may choose what
that means with the freedom of R116, and can just ignore the
requirement.
In addition to this argument, there is also game custom to support this
statement: R1442 requires the Assessor to bill _all_ voting entities "a
number of Voting Tokens equal to the votes cast". This includes entities
who didn't vote at all, to be billed for 0 VTs. This requirement has
never been fulfilled in another way than just by being ignored.
======================================================================
Judge's Arguments:
I hereby enter a Judgement of TRUE. I would have phrased the conclusion
differently (as "the Rules cannot impose a requirement to execute a
Payment Order for 0 units of a Currency"), but I agree with the Caller's
reasoning.
======================================================================
Evidence attached by CotC:
Rule 1596/3 (Power=1)
Payment Orders
A Payment Order is an Order requiring an entity (the payor) to
submit a Transfer Order transferring units of a Currency from
itself to some other entity (the payee). A Payment Order
specifies exactly one source entity, exactly one destination
entity, exactly one Currency, and a number of units of that
Currency which is a positive multiple of that Currency's MUQ.
======================================================================
--
Steve Gardner | Appearances to the contrary,
Dept. of Philosophy, Monash Uni. | things are just what they seem.