That doesn’t make sense. In this case, the number itself is the topping. The property at issue isn’t something that’s being numbered, it’s the number itself.
-Aris On Mon, Jul 1, 2019 at 7:17 PM Rebecca <edwardostra...@gmail.com> wrote: > Well no, you're asking for an impossible number of an existing topping. If > you went into a burger king and said "i want this burger with 1/2 of an > extra pickle" the employee would say "we cannot cut these pickles in half, > but we will give you one extra pickle, the default number of extra pickles" > > On Tue, Jul 2, 2019 at 10:28 AM Aris Merchant < > thoughtsoflifeandligh...@gmail.com> wrote: > > > I thought about this earlier. The problem I have with it is that > > there's no time at which the switch would fail to have a possible > > value. If the specified value is invalid, you don't create a proposal > > that would have an invalid value apart from that provision, you just > > fail, at least under my theory. The problem isn't that you're not > > specifying that you want the extra avocado; you're requesting to have > > your sandwich with an impossible feature, like asking for the sandwich > > with elephant egg omelet topping. At that point, the waiter tells you > > you're insane and you're refused service, or at the very least > > politely asked to make a valid order. > > > > -Aris > > > > On Mon, Jul 1, 2019 at 5:19 PM Kerim Aydin <ke...@uw.edu> wrote: > > > > > > > > > I'm actually coming round to D. Margaux's result now, but for a bit of > a > > > different, more narrow reason. R2162(Switches) says: > > > > If an > > > > instance of a switch would otherwise fail to have a possible > > > > value, it comes to have its default value. > > > > > > If you created a proposal with AI=0.5, it would absolutely fail to have > > > a possible value - therefore it goes to default as the proposal is > > > created. And I think this pretty strongly maps onto the concept of > > > "default" and "optional". Just in common language, if you order > > > off a menu and don't specify that you want the extra avocado, they > > > don't say "you didn't say which options you wanted, no food for you", > > > they serve up the default. > > > > > > On 7/1/2019 3:31 PM, Aris Merchant wrote: > > > > I’d propose a different theory. Mine is cleaner and simpler, but I’m > > not > > > > entirely sure which is actually better. Barring someone is a separate > > > > action from calling the CFJ; it just has to be done in the same > > message. By > > > > contrast, it’s a tad hard to argue that specifying the AI of a > > proposal is > > > > somehow separately from specifying the rest of its properties. So it > > makes > > > > logical sense that barring should be able to succeed or fail > > atomically, > > > > whereas specifying a proposal’s AI shouldn’t. G., any opinion on > which > > of > > > > these explanations better fits with Agoran practice? > > > > > > > > -Aris > > > > > > > > On Mon, Jul 1, 2019 at 11:44 AM Jason Cobb <jason.e.c...@gmail.com> > > wrote: > > > > > > > >> IANAAL (I am not an Agora lawyer). > > > >> > > > >> I think that a key difference between those two scenarios is whether > > or > > > >> not the invalid action affects the gamestate. For instance, the AI > of > > a > > > >> proposal is a key part of the proposal's identity, it will affect > > > >> whether or not it gets adopted, what it can do, etc. Changing the AI > > of > > > >> a proposal makes the consequences of the proposal vastly different, > so > > > >> it makes sense not to do that implicitly. While for the CFJ > scenario, > > > >> the difference between the barring succeeding and failing is > nothing - > > > >> if the barring succeeded, then the non-person couldn't judge anyway, > > so > > > >> no difference to the gamestate than if it failed. > > > >> > > > >> Jason Cobb > > > >> > > > >> On 7/1/19 11:16 AM, Kerim Aydin wrote: > > > >>> > > > >>> On 6/30/2019 11:32 PM, D. Margaux wrote: > > > >>>> If a player does all that and also specifies that AI=e, I don't > see > > > >>>> why that makes the CAN clause fail. > > > >>> > > > >>> It's impossible to create a Proposal with AI=0.5. If I say "I > > create the > > > >>> following proposal with AI=0.5" it's equally reasonably to say "no > > you > > > >>> didn't, that's IMPOSSIBLE to do and it fails" as it is to say "you > > got > > > >>> that > > > >>> half right - you made a proposal but it's a different (default) > AI." > > > >>> With those being equally reasonable in a vacuum (IMO), we've tended > > in > > > >>> interpretation to err on the side of complete failure, for > practical > > > >>> reasons. It's so much easier to simply say "whoops, no action, try > > > >>> again" > > > >>> then to say "you did it half-right and now we have to clean up the > > > >>> mess of > > > >>> the half-correct proposal." > > > >>> > > > >>> I'm not sure if there's a general principle here. For some things > > (like > > > >>> paying fees) we really stick with complete failure - e.g. if you > try > > > >>> to pay > > > >>> a fee and only have 1/2 the number of coins, we don't say "you paid > > > >>> half and > > > >>> then fail to perform the action" - there's an implicit "if this fee > > > >>> can't be > > > >>> paid in full, it fails". > > > >>> > > > >>> On the other hand, let's say you call a CFJ and try to bar a > > > >>> non-person from > > > >>> judging for some silly reason. That "bar" fails, but I'm guessing > > > >>> we'd just > > > >>> let the CFJ go through - because the CFJ-calling and the barring > are > > > >>> somewhat weakly connected. > > > >>> > > > >>> This is all to say - this seems like the sort of thing were some > > general > > > >>> principles/tests along the continuum of success/failure are worth > > > >>> figuring > > > >>> out. > > > >> > > > > > -- > From R. Lee >
