rails-devel

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[Erik V. <eri...@xs...>]

The below observation by Martin is also pertinent to our discussion:

> From: Dr....@t-... [mailto:Dr....@t-...] 
> keep in mind that there are games lurking in the wood that have higher denominations and not even a fixed one for the portfolio at start.
> And yes of course prime example: 1880 -> The president share might be a 20, 30 or 40 percent share and thus subsequently the number of shares per company might not be known until the corporation has started.

In 1880 there is no dispute what a share is: 10%.

However, for me the interesting aspect of this observation is, that in 1880 we do not know beforehand how many certificates we have, and what number of shares at least one certificate represents.   The 1856 situation is very similar, but in this case the undefinedness applies to all CGR certificates.

In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and 18 of 5%.  Should the CGR need only 10 shares, then Rails throws away ten 5% certificates, and doubles the share unit value of the company, which automatically converts the remaining nine certificates from 10% to 20% and from 5% to 10%, without need to affect the number of share units each cert represents.

In 1880 I would solve this by initializing with one 20% and eight 10% certificates.  Should the company start with a 30% or 40% president certificate, then the number of share units of that cert will be raised from 2 to 3 or 4, and one or two 10% certs will be discarded.

> From: Stefan Frey [mailto:ste...@we...]
> * I disagree the concept of "share" should be objects in Rails. I prefer the
> nominal (percentage) being an attribute of the certificates.

I'm with Stefan in this matter.

> So my suggestion (derived from all input from the current discussion) is:
> 
> A) Use one class that represents share certificates types. Use another class
> that represent concrete share certificates (similar to trains and train types,
> and this would be required for your proposal as well).
> 
> B) Share certificate types have an attribute called nominal_percentage (or
> nominal percentage) which defines what their contribution to the total
> capital stock is and another boolean attribute which defines president or not.
> 
> C) Each company defines an attribute called quotation_percentage which
> defines the percentage of stock ownership the stock market price
> corresponds to. The selling and purchase price for each certificate then
> equals (nominal_percentage / quotation_percentage) * stock_price.

What we currently have is:

CC) Companies have two attributes relevant to this discussion:
- The "share unit", which is the size of its smallest share (which can vary from 5% to 100%),
- the "share price unit", which is the number of share units that the share price applies to.  Always 1, except for the PR.

DD) Each cert has an attribute named "shares" that represents the number of share units represented by that certificate. In the light of the previous discussion it has become clear, that we should rename this attribute to "number of share units". (Of course there is also a "president" boolean).

A main difference with Stefan's proposal is the current existence of an additional "share unit" company attribute, which is the base percentage in which all share amounts are expressed.  I think I introduced this attribute with 1856 to facilitate the share conversion that may occur during the CGR formation (see above).  My strong preference is to retain this structure.

Do we really need certificate types as in B)?  I don't see a big need for such an additional type (whereby I realize that as yet we are not prepared for the "lunatic designer" syndrome that Stefan envisions).  But I'm not firmly against either. In any case, if we introduce such a concept, we must have a strategy for handling the 1880 and 1856 cases.  In these games we must be prepared to either:
- define all possible cert types beforehand, and change the cert type of some or all certificates of a company, as needed, or
- change the parameters of some cert types, as needed. 
In particular for 1880 the question then arises if cert types will be defined per company, or just once for all companies.

Also keep in mind that in Rails every persistent attribute that can change value must be a state variable.  Currently, shareUnit is an IntegerState, on behalf of 1856.  In hindsight, I could have chosen to leave it an integer, but to replace that in PublicCompany_CGR by an IntegerState, forcing all access to either to use a method.  I would suggest to use the latter approach in 1880, by overriding the integer "shares" (or rather "numberOfShareUnits") by an IntegerState in a specific class PublicCertificate_1880.  

Erik.

 

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[Erik V. <eri...@xs...>]

Oh, and don't forget that pretty soon we will be faced with companies that
convert from 5-share to 10-share companies (and even worse), as occurs in
several David Hecht games (e.g. 1826 and 18FL).  Again I think this is most
easily addressed by changing the share unit, and in addition changing the
owner of the additional five (as yet unavailable) certificates.  That's all
existing stuff.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Friday, November 18, 2011 8:09 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835
testing)
> 
> The below observation by Martin is also pertinent to our discussion:
> 
> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > keep in mind that there are games lurking in the wood that have higher
> denominations and not even a fixed one for the portfolio at start.
> > And yes of course prime example: 1880 -> The president share might be a
> 20, 30 or 40 percent share and thus subsequently the number of shares per
> company might not be known until the corporation has started.
> 
> In 1880 there is no dispute what a share is: 10%.
> 
> However, for me the interesting aspect of this observation is, that in
1880 we
> do not know beforehand how many certificates we have, and what number
> of shares at least one certificate represents.   The 1856 situation is
very
> similar, but in this case the undefinedness applies to all CGR
certificates.
> 
> In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and
18 of
> 5%.  Should the CGR need only 10 shares, then Rails throws away ten 5%
> certificates, and doubles the share unit value of the company, which
> automatically converts the remaining nine certificates from 10% to 20% and
> from 5% to 10%, without need to affect the number of share units each cert
> represents.
> 
> In 1880 I would solve this by initializing with one 20% and eight 10%
> certificates.  Should the company start with a 30% or 40% president
> certificate, then the number of share units of that cert will be raised
from 2
> to 3 or 4, and one or two 10% certs will be discarded.
> 
> > From: Stefan Frey [mailto:ste...@we...]
> > * I disagree the concept of "share" should be objects in Rails. I
> > prefer the nominal (percentage) being an attribute of the certificates.
> 
> I'm with Stefan in this matter.
> 
> > So my suggestion (derived from all input from the current discussion)
is:
> >
> > A) Use one class that represents share certificates types. Use another
> > class that represent concrete share certificates (similar to trains
> > and train types, and this would be required for your proposal as well).
> >
> > B) Share certificate types have an attribute called nominal_percentage
> > (or nominal percentage) which defines what their contribution to the
> > total capital stock is and another boolean attribute which defines
president
> or not.
> >
> > C) Each company defines an attribute called quotation_percentage which
> > defines the percentage of stock ownership the stock market price
> > corresponds to. The selling and purchase price for each certificate
> > then equals (nominal_percentage / quotation_percentage) * stock_price.
> 
> What we currently have is:
> 
> CC) Companies have two attributes relevant to this discussion:
> - The "share unit", which is the size of its smallest share (which can
vary from
> 5% to 100%),
> - the "share price unit", which is the number of share units that the
share
> price applies to.  Always 1, except for the PR.
> 
> DD) Each cert has an attribute named "shares" that represents the number
> of share units represented by that certificate. In the light of the
previous
> discussion it has become clear, that we should rename this attribute to
> "number of share units". (Of course there is also a "president" boolean).
> 
> A main difference with Stefan's proposal is the current existence of an
> additional "share unit" company attribute, which is the base percentage in
> which all share amounts are expressed.  I think I introduced this
attribute
> with 1856 to facilitate the share conversion that may occur during the CGR
> formation (see above).  My strong preference is to retain this structure.
> 
> Do we really need certificate types as in B)?  I don't see a big need for
such an
> additional type (whereby I realize that as yet we are not prepared for the
> "lunatic designer" syndrome that Stefan envisions).  But I'm not firmly
against
> either. In any case, if we introduce such a concept, we must have a
strategy
> for handling the 1880 and 1856 cases.  In these games we must be prepared
> to either:
> - define all possible cert types beforehand, and change the cert type of
some
> or all certificates of a company, as needed, or
> - change the parameters of some cert types, as needed.
> In particular for 1880 the question then arises if cert types will be
defined per
> company, or just once for all companies.
> 
> Also keep in mind that in Rails every persistent attribute that can change
> value must be a state variable.  Currently, shareUnit is an IntegerState,
on
> behalf of 1856.  In hindsight, I could have chosen to leave it an integer,
but to
> replace that in PublicCompany_CGR by an IntegerState, forcing all access
to
> either to use a method.  I would suggest to use the latter approach in
1880,
> by overriding the integer "shares" (or rather "numberOfShareUnits") by an
> IntegerState in a specific class PublicCertificate_1880.
> 
> Erik.
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> 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. IT
> sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[John A. T. <ja...@ja...>]

Note that several games have particular certificates that have different
sizes, such as 18TN having a 30% presidency for IC, several of Gary
Mroczka's games have doubled non-director shares for the last share (I
believe 1835 also does this).  So, you need to be able to order the certs
available from the IPO specifically.  1844 also has 4 share companies, and
many have 5-share companies that become 10-share companies.  18Dixie has
preferred certificates which do not count against the 60% limit.

So, I think you do want to model particular certificates owned by a player,
rather than just keeping track of share count / percentage.

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[Erik V. <eri...@xs...>]

Yes, and that is exactly what we do behind the scenes. 

I have just added a moveover message (tooltip) that shows the split of the grand total share percentage that has so far been the only display per player per company.


Erik.

 

From: John A. Tamplin [mailto:ja...@ja...] 
Sent: Friday, November 18, 2011 9:05 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

 

Note that several games have particular certificates that have different sizes, such as 18TN having a 30% presidency for IC, several of Gary Mroczka's games have doubled non-director shares for the last share (I believe 1835 also does this).  So, you need to be able to order the certs available from the IPO specifically.  1844 also has 4 share companies, and many have 5-share companies that become 10-share companies.  18Dixie has preferred certificates which do not count against the 60% limit.

 

So, I think you do want to model particular certificates owned by a player, rather than just keeping track of share count / percentage.

 

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[John A. T. <ja...@ja...>]

On Fri, Nov 18, 2011 at 5:26 PM, Erik Vos <eri...@xs...> wrote:

> Yes, and that is exactly what we do behind the scenes. ****
>
> I have just added a moveover message (tooltip) that shows the split of the
> grand total share percentage that has so far been the only display per
> player per company.
>

Sorry, I read the message I replied to as suggesting a change that would
have broken that.

-- 
John A. Tamplin

Re: [Rails-devel] Shares and certificates (was: Further 1835 testing)

[Stefan F. <ste...@we...>]

Erik:
A general remark first regarding the Rails 2.0 development:

It is already quite often not possible to automatic (=merge without manual 
intervention) rebase the 2.0 branch onto the Rails 1.x master as the changes 
to the base elements (states, moves, portfolios) are too substantial. So I can 
only merge commits one-by-one, which takes some effort.

Most likely I will not be able (auto-)merge any of your changes regarding 
shares into the 2.0 branch. And due to the nature of changes it will be easier 
to implement the changes directly instead of the trying to merge the 1.x 
commits.

So from my point of view I recommend to keep your changes minimal in able to 
fix 1835. However your decision will mainly depend on how long you expect to 
keep developing in Rails 1.x. 

Unfortunately I am currently not able to give a clear commitment when Rails 
2.0 will run without errors.
Of the design/refactoring changes for the initial 2.0 I think 90% are in 
place, however from the testing/bug-hunting I guess only 10% are done, but the 
latter figure is difficult to predict.

I will provide more feedback on your proposal later this weekend.

Stefan

On Friday, November 18, 2011 08:08:49 pm Erik Vos wrote:
> The below observation by Martin is also pertinent to our discussion:
> > From: Dr....@t-... [mailto:Dr....@t-...]
> > keep in mind that there are games lurking in the wood that have higher
> > denominations and not even a fixed one for the portfolio at start. And
> > yes of course prime example: 1880 -> The president share might be a 20,
> > 30 or 40 percent share and thus subsequently the number of shares per
> > company might not be known until the corporation has started.
> 
> In 1880 there is no dispute what a share is: 10%.
> 
> However, for me the interesting aspect of this observation is, that in 1880
> we do not know beforehand how many certificates we have, and what number
> of shares at least one certificate represents.   The 1856 situation is
> very similar, but in this case the undefinedness applies to all CGR
> certificates.
> 
> In 1856 this is solved by initializing the CGR with 19 certs: 1 of 10% and
> 18 of 5%.  Should the CGR need only 10 shares, then Rails throws away ten
> 5% certificates, and doubles the share unit value of the company, which
> automatically converts the remaining nine certificates from 10% to 20% and
> from 5% to 10%, without need to affect the number of share units each cert
> represents.
> 
> In 1880 I would solve this by initializing with one 20% and eight 10%
> certificates.  Should the company start with a 30% or 40% president
> certificate, then the number of share units of that cert will be raised
> from 2 to 3 or 4, and one or two 10% certs will be discarded.
> 
> > From: Stefan Frey [mailto:ste...@we...]
> > * I disagree the concept of "share" should be objects in Rails. I prefer
> > the nominal (percentage) being an attribute of the certificates.
> 
> I'm with Stefan in this matter.
> 
> > So my suggestion (derived from all input from the current discussion) is:
> > 
> > A) Use one class that represents share certificates types. Use another
> > class that represent concrete share certificates (similar to trains and
> > train types, and this would be required for your proposal as well).
> > 
> > B) Share certificate types have an attribute called nominal_percentage
> > (or nominal percentage) which defines what their contribution to the
> > total capital stock is and another boolean attribute which defines
> > president or not.
> > 
> > C) Each company defines an attribute called quotation_percentage which
> > defines the percentage of stock ownership the stock market price
> > corresponds to. The selling and purchase price for each certificate then
> > equals (nominal_percentage / quotation_percentage) * stock_price.
> 
> What we currently have is:
> 
> CC) Companies have two attributes relevant to this discussion:
> - The "share unit", which is the size of its smallest share (which can vary
> from 5% to 100%), - the "share price unit", which is the number of share
> units that the share price applies to.  Always 1, except for the PR.
> 
> DD) Each cert has an attribute named "shares" that represents the number of
> share units represented by that certificate. In the light of the previous
> discussion it has become clear, that we should rename this attribute to
> "number of share units". (Of course there is also a "president" boolean).
> 
> A main difference with Stefan's proposal is the current existence of an
> additional "share unit" company attribute, which is the base percentage in
> which all share amounts are expressed.  I think I introduced this
> attribute with 1856 to facilitate the share conversion that may occur
> during the CGR formation (see above).  My strong preference is to retain
> this structure.
> 
> Do we really need certificate types as in B)?  I don't see a big need for
> such an additional type (whereby I realize that as yet we are not prepared
> for the "lunatic designer" syndrome that Stefan envisions).  But I'm not
> firmly against either. In any case, if we introduce such a concept, we
> must have a strategy for handling the 1880 and 1856 cases.  In these games
> we must be prepared to either: - define all possible cert types
> beforehand, and change the cert type of some or all certificates of a
> company, as needed, or - change the parameters of some cert types, as
> needed.
> In particular for 1880 the question then arises if cert types will be
> defined per company, or just once for all companies.
> 
> Also keep in mind that in Rails every persistent attribute that can change
> value must be a state variable.  Currently, shareUnit is an IntegerState,
> on behalf of 1856.  In hindsight, I could have chosen to leave it an
> integer, but to replace that in PublicCompany_CGR by an IntegerState,
> forcing all access to either to use a method.  I would suggest to use the
> latter approach in 1880, by overriding the integer "shares" (or rather
> "numberOfShareUnits") by an IntegerState in a specific class
> PublicCertificate_1880.
> 
> Erik.
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- 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. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel