Re: [Rails-devel] Further 1835 testing

[brett l. <bre...@gm...>]

I'll just note that your method doesn't solve the problem in any fewer
classes than mine does. You have CertType and Cert, where I have Cert
and Share. This appears to be the same bike shed, just painted a
different color.

Your way seems to work just fine, too. I've got no objections to it. :-)

---Brett.



On Fri, Nov 18, 2011 at 10:38 AM, Stefan Frey <ste...@we...> wrote:
> Brett,
> I agree and disagree with you at the same time:
>
> * I agree that the concepts of certificate and "share" should be clearly
> distinguished.
>
> * I disagree the concept of "share" should be objects in Rails. I prefer the
> nominal (percentage) being an attribute of the certificates.
>
> 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.
>
>
> For 1835 the following certification types would be defined:
>
> Major PR:
> * One certification type "President share", nominal_percentage = 10% and
> president = yes
> * One certification type "10% share", nominal_percentage = 10%, president = no
> * One certification type "5%share", nominal_percentage = 5%
> And the quotation_percentage is 10%.
>
> For all other majors except BY,SX:
> * One certification type "President share", nominal_percentage = 20% and
> president = yes
> * One certification type "20% share", nominal_percentage = 20%, president = no
> * One certification type "10% share", nominal_percentage = 10%
> And the quotation_percentage is 10%.
>
> For BY and SX:
> * One certification type "President share", nominal_percentage = 20% and
> president = yes
> * One certification type "10% share", nominal_percentage = 10%, president = no
> And the quotation_percentage is 10%.
>
> The major advantage is now that we do not have even to fear a lunatic game
> designer who defines a company with share capital divided into shares with
> 9%, 11%, 21%, 28%, 31% participation, for which the stock price is quoted for
> the 9% nominal ;-)
>
>
> Stefan
>
>
> On Friday, November 18, 2011 03:51:44 pm brett lentz wrote:
>> On Fri, Nov 18, 2011 at 4:50 AM, Stefan Frey <ste...@we...> wrote:
>> > On Friday, November 18, 2011 10:39:01 am Erik Vos wrote:
>> >> > 3) Most people's definition of a "share" is such that the stock price
>> >>
>> >> chart gives
>> >>
>> >> > the price of one share.  Therefore, a "share" is 10%.
>> >
>> There are two basic concepts that my gaming circle uses for 18xx games
>> that I think are well-suited for clarifying this issue.
>>
>> There's the "pieces of cardboard" or "certificates", which is used for
>> things like maximum certificate limits.
>> Then there's "shares" which are the divisible denominations of the
>> company ownership.
>>
>> Each "share" is divided up into face-value percentages, the most
>> common being 10%. However, a single "piece of cardboard" may have
>> multiple "shares" represented (e.g. the president's "certificate" is
>> really 2 "shares")
>>
>> So, in terms of internal code representation, we (should) have two
>> classes and a few properties.
>>
>> Class 1: Certificate.
>> - property: share_array
>>
>> Class 2: Share.
>> - property: base_percentage
>>
>>
>> So, for situations like 1856's formation of the CNR, it's actually a
>> decision of whether we're creating 10 10% shares (using 9
>> certificates) or 20 5% shares (using 19 certificates). This is part of
>> the process of the CNR formation, because it requires calculating how
>> many companies are being folded in.
>>
>> >> Yes, that is a sensible point of view.  One problem is, though, that we
>> >> must rethink how to report selling multiple shares.
>> >
>> > Erik I even wondered how you got everything consistent with his
>> > definition PR's share unit being 5%?
>> > I suspect you created a variable that defines something like "stock is
>> > quoted in multiples of 2".
>>
>> But you never sell "shares", you always sell "certificates" (i.e. the
>> piece of cardboard).  So, your transaction is always with the
>> "container" for the shares.
>>
>> >> If a player sells two 5% certificates, what did he sell in terms of
>> >> shares? One share?  Two 5% shares? Two half-shares?
>> >
>> > I prefer two "5% certificates". All other definitions end up being
>> > ambiguous in some constellation. I would even use an ID for the
>> > certificate types instead of the 5% attribute, as there might come up a
>> > game with various certificates that have the same nominal but differ in
>> > some other properties.
>>
>> I'm a little unclear on the 1835 situation. My thought would be that
>> the base "share" value should be whatever the smallest denomination
>> being used is.
>>
>> So, if there's 2x 5% shares floating around and everything else is
>> 10%, we should use 5% as the base value, and the whole company's set
>> of (cardboard) certificates should contain a number of share objects
>> that adequately represents their total value. This means that the
>> whole company has 20 "shares" of stock, divided into 10 (cardboard)
>> certificates. (e.g. 2x certificates at 5%, 7x certificates at 10% each
>> containing 2 shares, and 1x certificate at 20% which contains 4
>> shares.)
>>
>> Having two separate objects makes all of the math and logic *so* much
>> simpler.
>>
>> > Stefan
>>
>> ---Brett.
>>
>> ---------------------------------------------------------------------------
>> --- 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
>
> ------------------------------------------------------------------------------
> 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
>