Thread: [Rails-devel] Bug in 1856

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

 There is a bug in 1856.

 I own 10% of CPR and buys another 10%. Then I want to sell my 
 previously owned share, but I can't. Save file attached. I run Rails 
 1.5.

 /Arne Östlund
This only seems to occur if the second buy is from the IPO, not if from the Pool.  Strange.
I'll investigate. There might be a connection with the don't-sell-a-just-bought certificate rule.

Erik.

> -----Original Message-----
> From: ar...@gl... [mailto:ar...@gl...]
> Sent: Monday, October 03, 2011 8:25 AM
> To: rai...@li...
> Subject: [Rails-devel] Bug in 1856
> 
> 
>  There is a bug in 1856.
> 
>  I own 10% of CPR and buys another 10%. Then I want to sell my  previously
> owned share, but I can't. Save file attached. I run Rails  1.5.
> 
>  /Arne Östlund

Erik:
I will wait with a bug-fix release until you solved that one too.
Stefan

On Monday, October 03, 2011 06:44:22 pm Erik Vos wrote:
> This only seems to occur if the second buy is from the IPO, not if from the
> Pool.  Strange. I'll investigate. There might be a connection with the
> don't-sell-a-just-bought certificate rule.
> 
> Erik.
> 
> > -----Original Message-----
> > From: ar...@gl... [mailto:ar...@gl...]
> > Sent: Monday, October 03, 2011 8:25 AM
> > To: rai...@li...
> > Subject: [Rails-devel] Bug in 1856
> > 
> >  There is a bug in 1856.
> >  
> >  I own 10% of CPR and buys another 10%. Then I want to sell my 
> >  previously
> > 
> > owned share, but I can't. Save file attached. I run Rails  1.5.
> > 
> >  /Arne Östlund
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Erik,

As you may already have discovered, the problem is an interaction with the code that checks if a share fits into the pool and the code that checks if we can sell a just bought share.  In this case both of these checks are reducing the number of shares we can sell, i.e. the code is double counting in this case.  The easy fix is to add the check that 'number == shareCountPerUnit[i]' on line 442.

The problem is that this introduces another problem.  With this check added a player who owns only the presidency of a company may buy and then immediately sell a 10% certificate, which is currently forbidden by Rails.  A reading of the rulebook supports the way that Rails currently handles things: 

"A certificate cannot be sold during the stock turn it was purchased."

Steve Thomas's list of 1856 clarifications (at http://www.18xx.net/1856/1856f.htm) contradicts this, saying that:

{p12} A player may sell stock in a Corporation bought earlier in the same turn of a stock round but must retain at least one share in the Corporation just bought. If necessary the same certificate may be bought then sold immediately. For example, a player owning just the President's certificate of a Corporation may buy and then sell a share of that Corporation. [This ruling directly contradicts the statement on p12, but accurately reflects the intentions of Bill Dixon.]

This clarification agrees with the simple fix suggested above, but it disagrees with the rules.  The more complicated fix that agrees with the rules as written is to check if either 'number == shareCountPerUnit[i]' or in the case that the current player is the president and the company is *not* dumpable that 'number == shareCountPerUnit[i] - 2'.  It may also be simpler just to check if the space in the pool has reduced maxShareToSell and not decrement the number of shares available for sale if this is the case.

I'd have included a patch, but it's not clear to me what the best solution is.  If the implementation follows Steve Thomas's clarification list, then the fix is relatively simple and I am happy with it, but this would be a change in how Rails behaves.  If Rails is to follow the rulebook as written, then I'm not really happy with the fix listed above as it requires testing for things like dumpability well outside of where the code for that currently resides.

Bill

On 2011-10-04, at 0:44 , Erik Vos wrote:

> This only seems to occur if the second buy is from the IPO, not if from the Pool.  Strange.
> I'll investigate. There might be a connection with the don't-sell-a-just-bought certificate rule.
> 
> Erik.
> 
>> -----Original Message-----
>> From: ar...@gl... [mailto:ar...@gl...]
>> Sent: Monday, October 03, 2011 8:25 AM
>> To: rai...@li...
>> Subject: [Rails-devel] Bug in 1856
>> 
>> 
>> There is a bug in 1856.
>> 
>> I own 10% of CPR and buys another 10%. Then I want to sell my  previously
>> owned share, but I can't. Save file attached. I run Rails  1.5.
>> 
>> /Arne Östlund
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

In the context of stock rounds, I have always interpreted 'share' as to mean
a certain percentage of ownership (usually 10%), not a physical share.

The Rails implementation of this rule intends to follow that view: a player
may, at the end of a turn, not own less shares than he has bought in that
turn.
It seems to me that this corresponds to Steve's interpretation (because you
can only buy one share in a turn, you must retain at least one share if you
bought one).

Now the rules talk about 'certificates', which are physical shares, and I
suppose that's where a contradiction is seen. But if the designer has
(implicitly or explicitly) made clear that he actually meant 'shares', I see
no problem in following that clarification, which to me correctly catches
the spirit, if not the letter, of the rule as written.

Whether or not Rails had *correctly* implemented this all, is another
matter.  Certainly the source of a bought share (IPO or Pool) should not
matter, but it currently does, and that is what I need to sort out first.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Tuesday, October 04, 2011 6:50 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug in 1856
> 
> Erik,
> 
> As you may already have discovered, the problem is an interaction with the
> code that checks if a share fits into the pool and the code that checks if
we
> can sell a just bought share.  In this case both of these checks are
reducing
> the number of shares we can sell, i.e. the code is double counting in this
> case.  The easy fix is to add the check that 'number ==
shareCountPerUnit[i]'
> on line 442.
> 
> The problem is that this introduces another problem.  With this check
added
> a player who owns only the presidency of a company may buy and then
> immediately sell a 10% certificate, which is currently forbidden by Rails.
A
> reading of the rulebook supports the way that Rails currently handles
things:
> 
> "A certificate cannot be sold during the stock turn it was purchased."
> 
> Steve Thomas's list of 1856 clarifications (at
> http://www.18xx.net/1856/1856f.htm) contradicts this, saying that:
> 
> {p12} A player may sell stock in a Corporation bought earlier in the same
turn
> of a stock round but must retain at least one share in the Corporation
just
> bought. If necessary the same certificate may be bought then sold
> immediately. For example, a player owning just the President's certificate
of
> a Corporation may buy and then sell a share of that Corporation. [This
ruling
> directly contradicts the statement on p12, but accurately reflects the
> intentions of Bill Dixon.]
> 
> This clarification agrees with the simple fix suggested above, but it
disagrees
> with the rules.  The more complicated fix that agrees with the rules as
> written is to check if either 'number == shareCountPerUnit[i]' or in the
case
> that the current player is the president and the company is *not* dumpable
> that 'number == shareCountPerUnit[i] - 2'.  It may also be simpler just to
> check if the space in the pool has reduced maxShareToSell and not
> decrement the number of shares available for sale if this is the case.
> 
> I'd have included a patch, but it's not clear to me what the best solution
is.  If
> the implementation follows Steve Thomas's clarification list, then the fix
is
> relatively simple and I am happy with it, but this would be a change in
how
> Rails behaves.  If Rails is to follow the rulebook as written, then I'm
not really
> happy with the fix listed above as it requires testing for things like
> dumpability well outside of where the code for that currently resides.
> 
> Bill
> 
> 
> On 2011-10-04, at 0:44 , Erik Vos wrote:
> 
> > This only seems to occur if the second buy is from the IPO, not if from
the
> Pool.  Strange.
> > I'll investigate. There might be a connection with the
don't-sell-a-just-
> bought certificate rule.
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: ar...@gl... [mailto:ar...@gl...]
> >> Sent: Monday, October 03, 2011 8:25 AM
> >> To: rai...@li...
> >> Subject: [Rails-devel] Bug in 1856
> >>
> >>
> >> There is a bug in 1856.
> >>
> >> I own 10% of CPR and buys another 10%. Then I want to sell my
> >> previously owned share, but I can't. Save file attached. I run Rails
1.5.
> >>
> >> /Arne Östlund
> >
> >
> > ----------------------------------------------------------------------
> > -------- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Since I already have a fix sitting in a dev-branch, here is an Eclipse patch to fix the current problem.  If you'd rather fix it in some other way, please feel free :)

The result is that if you buy a share in a company in a stock turn, then at the end of the stock turn you must hold at least one share of that company.  This changes the way Rails behaves regarding presidencies.  It is now legal to start the turn with only the presidency of a company and buy and sell a single share.

I agree that this is the most reasonable interpretation, and it seems to correspond to the intent of the designer, but I wanted to be explicit that a change in behaviour is being made, even if no change in intent is present.

Bill

Bill, your fix did the job, but in a way that is not so easy to understand -
at least, it took me a while.

The underlying problem is, that one (the just bought) share was
unconditionally subtracted *after* the check was done if there is enough
space in the Pool.
Buying from the Pool creates space for two shares, buying from IPO leaves
one space. In the latter case, no further deduction should have happened.

I have now reversed the sequence of these two checks, and all is fine.  Your
fix essentially did the same thing, but now *I* can understand the code...:)

The test set also succeeds, apart from the usual KKÖB Unicode mismatch in
18EU.

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Tuesday, October 04, 2011 11:32 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Bug in 1856
> 
> Since I already have a fix sitting in a dev-branch, here is an Eclipse
patch to fix
> the current problem.  If you'd rather fix it in some other way, please
feel free
> :)
> 
> The result is that if you buy a share in a company in a stock turn, then
at the
> end of the stock turn you must hold at least one share of that company.
This
> changes the way Rails behaves regarding presidencies.  It is now legal to
start
> the turn with only the presidency of a company and buy and sell a single
> share.
> 
> I agree that this is the most reasonable interpretation, and it seems to
> correspond to the intent of the designer, but I wanted to be explicit that
a
> change in behaviour is being made, even if no change in intent is present.
> 
> Bill