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