Menu
▾
▴
rails-devel
|
From: Stefan F. <ste...@we...> - 2011-11-15 14:57:41
|
Erik: there has been great progress on 1835 recently, so I took the opportunity to do some testing of 1835. Seems that everything works fine, however there are at least two bugs concerning the handling of multiple share classes (10% and 20%, 5% and 10%) in 1835. And I think that if there are several share classes there should be an indication how your portfolio is split into those. Otherwise it can be quite confusing. Unfortunately from a technical point of view I have already rewritten the share/certificate model for Rails 2.0, so I will not be able to forward-port those changes to that branch. Stefan List of Bugs and Annoyances, see attached game files. Bugs: A) Player T2 nationalizes BA from T3: There is no option to nationalize the 20% certificate first. B) Player T3 sells 30% of WT: There is no selection to chosse either one 20% or two 10% certificates for exchange of the president certificate. Annoyances: A) For Player T3 PR is shown as buyable (shares are highlighted), even if funds are not sufficient. However after selecting an error message says that "T3 cannot buy 2 share(s) of PR from IPO: Not enough money". The message is correct, however it is not 2 shares, but the larger 10% certificate. B) After laying/upgrading one tile already, SX still has the option to use the special property of Pfalzbahn. However on clicking on L6 an error message says that "At the moment there is not valid tile or upgrade for this hex.", this is wrong. Same case can be shown for OBB (given a tile lay before). Reversing the sequence (first laying special property, then normal tile lay, works however). |
|
From: Erik V. <eri...@xs...> - 2011-11-16 17:53:29
|
All correct, except for one remark (see below). Another main annoyance with 1835 is that it's unclear to see which portfolios contain non-president double shares. Several people have already complained about that, and I will try to address that first. I'll probably add portfolio composition info to each %-field tooltip, adding such info to the ShareModel update info. We may need additional ShareField/ShareClickField classes to parse and hold that info. This will then be a generic feature. Erik. > List of Bugs and Annoyances, see attached game files. > > Bugs: > A) Player T2 nationalizes BA from T3: There is no option to nationalize the > 20% certificate first. > B) Player T3 sells 30% of WT: There is no selection to chosse either one 20% > or two 10% certificates for exchange of the president certificate. > > Annoyances: > A) For Player T3 PR is shown as buyable (shares are highlighted), even if > funds are not sufficient. > However after selecting an error message says that "T3 cannot buy 2 share(s) > of PR from IPO: Not enough money". > The message is correct, however it is not 2 shares, but the larger 10% > certificate. The PR share unit size is 5%, so a 10% certificate is two shares. The 1835 rules do not very clearly distinguish between certificates and shares, but we have to. > B) After laying/upgrading one tile already, SX still has the option to use the > special property of Pfalzbahn. However on clicking on L6 an error message > says that "At the moment there is not valid tile or upgrade for this hex.", this > is wrong. > Same case can be shown for OBB (given a tile lay before). Reversing the > sequence (first laying special property, then normal tile lay, works however). |
|
From: Stefan F. <ste...@we...> - 2011-11-17 11:09:40
|
see comment below. On Wednesday, November 16, 2011 06:53:25 pm Erik Vos wrote: > All correct, except for one remark (see below). > > A) For Player T3 PR is shown as buyable (shares are highlighted), even if > > funds are not sufficient. > > However after selecting an error message says that "T3 cannot buy 2 > > share(s) > > > of PR from IPO: Not enough money". > > The message is correct, however it is not 2 shares, but the larger 10% > > certificate. > > The PR share unit size is 5%, so a 10% certificate is two shares. > The 1835 rules do not very clearly distinguish between certificates and > shares, but we have to. You are right from a logical and an implementation point of view. Still I find the wording confusing, because of two reasons: A) 1835 and PR specific For me (thus subjective) in 1835 the share unit for PR seems to be 10%. So if I would use the word share (see below) the 5% shares are more like half a share. This also corresponds to the standard in 18xx, where most of the time the 10% is the typical share unit. A) The word in shares in this context For me a share is still more associated with the actual certificate than the participation right. Due to this reason I would prefer the error message to make this clear. Otherwise the user might get confused because he does not distinguish between share and certificate here. Example: "T3 cannot buy 1 certificate(s) with 10% of PR from IPO)". However this issue should be decided by native speakers as the usual translation for share in German is "Aktie" - which clearly refers to the certificate, the other translation "Anteil" - which refers to the participation right is less common. Stefan |
|
From: Erik V. <eri...@xs...> - 2011-11-16 22:11:12
|
Done. No extra classes. The portfolio composition tooltip is not sorted in any way. I suspect that's not too annoying. Erik. > Another main annoyance with 1835 is that it's unclear to see which portfolios > contain non-president double shares. Several people have already > complained about that, and I will try to address that first. > I'll probably add portfolio composition info to each %-field tooltip, adding > such info to the ShareModel update info. We may need additional > ShareField/ShareClickField classes to parse and hold that info. This will then > be a generic feature. |
|
From: Stefan F. <ste...@we...> - 2011-11-17 10:56:10
|
Works fine and I like that. However I would prefer not to show up in games where it does not matter (i.e. P are 20% and all others shares are 10%), but I am open to other opinions here. The only annoying bit is that a small rectangle (an empty tool-tip) appears for those cells without any shares. Stefan On Wednesday, November 16, 2011 11:11:05 pm Erik Vos wrote: > Done. No extra classes. > The portfolio composition tooltip is not sorted in any way. I suspect > that's not too annoying. > > Erik. > > > Another main annoyance with 1835 is that it's unclear to see which > > portfolios > > > contain non-president double shares. Several people have already > > complained about that, and I will try to address that first. > > I'll probably add portfolio composition info to each %-field tooltip, > > adding > > > such info to the ShareModel update info. We may need additional > > ShareField/ShareClickField classes to parse and hold that info. This > > will then > > > be a generic feature. > > --------------------------------------------------------------------------- > --- 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 |
|
From: Erik V. <eri...@xs...> - 2011-11-18 10:46:42
|
> Works fine and I like that. However I would prefer not to show up in games > where it does not matter (i.e. P are 20% and all others shares are 10%), but I > am open to other opinions here. That would require an extra company property. But let's first see if we get any complaints. > The only annoying bit is that a small rectangle (an empty tool-tip) appears for > those cells without any shares. Fixed (not yet pushed). Erik. |
|
From: <Dr....@t-...> - 2011-11-18 14:07:10
|
Hi Guys, 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. The german "Papier" comes to mind a "Papier" might be a Private Company, but also a 5/10/20/30/40 percent certificate. The smalles denomination currently is of course the 5% one but who knows what the future will bring ? So shouldnt we define a configurable "Denomination property" per game ? Regards, Martin Von: "Erik Vos" <eri...@xs...> An: "'Development list for Rails: an 18xx game'" <rai...@li...> Betreff: Re: [Rails-devel] Further 1835 testing Datum: Fri, 18 Nov 2011 11:46:32 +0100 > Works fine and I like that. However I would prefer not to show up in games > where it does not matter (i.e. P are 20% and all others shares are 10%), but I > am open to other opinions here. That would require an extra company property. But let's first see if we get any complaints. > The only annoying bit is that a small rectangle (an empty tool-tip) appears for > those cells without any shares. Fixed (not yet pushed). 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 |
|
From: John D. G. <jd...@di...> - 2011-11-18 06:49:30
|
> Erik Vos wrote: >> The PR share unit size is 5%, so a 10% certificate is two shares. >> The 1835 rules do not very clearly distinguish between certificates and >> shares, but we have to. Stefan Frey wrote: > You are right from a logical and an implementation point of view. Still I find > the wording confusing, because of two reasons: > > A) 1835 and PR specific > For me (thus subjective) in 1835 the share unit for PR seems to be 10%. So if > I would use the word share (see below) the 5% shares are more like half a > share. This also corresponds to the standard in 18xx, where most of the time > the 10% is the typical share unit. > > A) The word in shares in this context > For me a share is still more associated with the actual certificate than the > participation right. Due to this reason I would prefer the error message to > make this clear. Otherwise the user might get confused because he does not > distinguish between share and certificate here. Example: "T3 cannot buy 1 > certificate(s) with 10% of PR from IPO)". 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%. |
|
From: Erik V. <eri...@xs...> - 2011-11-18 09:39:08
|
> 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%. Yes, that is a sensible point of view. One problem is, though, that we must rethink how to report selling multiple shares. If a player sells two 5% certificates, what did he sell in terms of shares? One share? Two 5% shares? Two half-shares? Erik. |
|
From: Stefan F. <ste...@we...> - 2011-11-18 09:47:49
|
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%. > That is definitely the best argument. for PR's share unit being 10%. Could someone remind me (as a newbie to 1856) how does it work for the Candian government railway if it issues 20 shares? Does the share price reflects still 10% or does it refer to 5%? > 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". > 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. Stefan |
|
From: Erik V. <eri...@xs...> - 2011-11-18 10:26:58
|
> > > 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%. > > That is definitely the best argument. for PR's share unit being 10%. > Could someone remind me (as a newbie to 1856) how does it work for the > Candian government railway if it issues 20 shares? Does the share price > reflects still 10% or does it refer to 5%? 5%. > 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". Exactly: that's the variable shareUnitsForSharePrice in PublicCompany. It's configurable: <ShareUnit percentage="5" sharePriceUnits="2"/> for the PR. > > 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. Yes, that's probably the best approach. > 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. Hmm, that might even enable consistent sorting of the details in the new portfolio composition tooltip. Erik. |
|
From: brett l. <bre...@gm...> - 2011-11-18 14:52:12
|
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%. >> > > That is definitely the best argument. for PR's share unit being 10%. > Could someone remind me (as a newbie to 1856) how does it work > for the Candian government railway if it issues 20 shares? Does the share > price reflects still 10% or does it refer to 5%? > 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. |
|
From: Phil D. <de...@gm...> - 2011-11-18 14:59:39
|
On 18 November 2011 14:51, brett lentz <bre...@gm...> wrote: > But you never sell "shares" Not always true, there are several cases where you can sell a share and receive change in the form of certificates of a different denomination. I don't think that actually affects your suggestions but it isn't true that you can only sell certificates since you can change them in in the correct scenarios. |
|
From: brett l. <bre...@gm...> - 2011-11-18 15:08:03
|
On Fri, Nov 18, 2011 at 9:59 AM, Phil Davies <de...@gm...> wrote: > On 18 November 2011 14:51, brett lentz <bre...@gm...> wrote: >> But you never sell "shares" > > Not always true, there are several cases where you can sell a share > and receive change in the form of certificates of a different > denomination. I don't think that actually affects your suggestions > but it isn't true that you can only sell certificates since you can > change them in in the correct scenarios. > You're absolutely right. This is what I get for trying to be coherent on 4 hours of sleep. ;-) ---Brett. |
|
From: Stefan F. <ste...@we...> - 2011-11-18 15:35:37
|
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 |
|
From: brett l. <bre...@gm...> - 2011-11-18 16:12:12
|
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 > |
|
From: Stefan F. <ste...@we...> - 2011-11-18 16:54:35
|
Brett, ... first some nit-picking: Your proposal would still need corresponding type classes at least for certificates, most likely for shares too, so you got at least 3 or 4 classes ;-) But anyway minimizing the number of classes was not the design goal of the proposal, however its great if you can live with it. In any case my proposal is still very close to what the current implementation is, it only removes the restriction that shares have to be a (integer) multiple of something like a "base percentage". I thinks this was the (historical) reason for Erik to decide that PR has a base unit of 5% as 1/2 unfortunately is not an Integer... So let us wait for Erik's opinion. Stefan On Friday, November 18, 2011 05:11:44 pm brett lentz wrote: > 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 > > --------------------------------------------------------------------------- > --- 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 |
|
From: Erik V. <eri...@xs...> - 2011-11-19 13:44:23
|
> Bugs: > A) Player T2 nationalizes BA from T3: There is no option to nationalize the > 20% certificate first. Fixed. The nationalization code has been largely rewritten. Also fixed the empty tooltips. Erik. |
|
From: John D. G. <jd...@di...> - 2011-11-20 03:18:07
|
I found one more real bug in 1835 on Rails 1.5.3: After the 5-train purchase forces all minors to merge into PR, PR is allowed to keep four trains. (The rules say PR is allowed only three after the 5-train purchase, while all other companies are allowed two.) |
|
From: John D. G. <jd...@di...> - 2011-11-20 04:12:03
|
On 2011-11-19 19:17, John David Galt wrote: > I found one more real bug in 1835 on Rails 1.5.3: > > After the 5-train purchase forces all minors to merge into PR, PR is allowed > to keep four trains. (The rules say PR is allowed only three after the > 5-train purchase, while all other companies are allowed two.) Follow-up: When the 6-train is purchased, then the program makes PR discard down to the correct limit of three trains, so it just happens late. |
|
From: Erik V. <eri...@xs...> - 2011-11-23 16:25:19
|
That's indeed a real bug. I also discovered that the PR probably would never discard more than one train if having more than one excess train. Both bugs are fixed now. Discarding multiple PR trains now takes separate player actions. An obvious improvement would be to enable the DiscardTrain action to require discarding more than one train in the same player action. Erik. > -----Original Message----- > From: John David Galt [mailto:jd...@di...] > Sent: Sunday, November 20, 2011 4:18 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Further 1835 testing > > I found one more real bug in 1835 on Rails 1.5.3: > > After the 5-train purchase forces all minors to merge into PR, PR is allowed to > keep four trains. (The rules say PR is allowed only three after the 5-train > purchase, while all other companies are allowed two.) > > ---------------------------------------------------------------------------- -- > 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 |
|
From: John D. G. <jd...@di...> - 2011-11-20 04:23:24
Attachments:
1835_20111120_0410_John.rails
|
This save file is a later one from the same game, and shows an amusing stock-market bug. At the point of the save, John has three 20% certificates of OL. If I click to sell some of them, the program offers to let me sell either one or two 10% certificates, or one or two 20% certs, but not three 20% certs. (So apparently the game engine "thinks" I have two 20% and two 10% certs, but that is not possible -- with 30% still in the IPO, only one 10% cert has ever been purchased.) It gets even more interesting if I take the program up on its offer to let me sell one 10% cert. When I do this, I am credited with 86M and the share price falls as if the sale had taken place -- but all holdings stay the same: I still own 60%. It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but I can "sell" another 10%, again gaining the market price of one share and dropping the price further while giving up nothing. (The "Game Report" window does not reflect the Undo so maybe that is a no-op here.) (A possibly related annoyance I found earlier: If Marcus wants to sell some of his 15% holding of PR, the interface allows him to sell either his 5% certificate or his 10% cert, but not both at the same time. I can sell one at a time, but this causes the price to fall twice, which is not possible under the rules of 1835.) |
|
From: Erik V. <eri...@xs...> - 2011-11-20 11:41:05
|
I'm working on share selling right now because of bugs reported by Stefan, and I'll will also pick up these problems. One remark for now: selling any mixtures of 5% and 10% shares in one action has been deliberately omitted for the sake of simplicity. Two separate actions are required. The default behaviour of Rails is (was? In any case: should be) that in 1835 the price will NOT fall again in such a case (and that the selling price remains the same). I will check what actually happens. Erik. > -----Original Message----- > From: John David Galt [mailto:jd...@di...] > Sent: Sunday, November 20, 2011 5:23 AM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Further 1835 testing > > This save file is a later one from the same game, and shows an amusing > stock-market bug. > > At the point of the save, John has three 20% certificates of OL. > If I click to sell some of them, the program offers to let me sell either one or > two 10% certificates, or one or two 20% certs, but not three 20% certs. (So > apparently the game engine "thinks" I have two 20% and two 10% certs, but > that is not possible -- with 30% still in the IPO, only one 10% cert has ever > been purchased.) > > It gets even more interesting if I take the program up on its offer to let me > sell one 10% cert. When I do this, I am credited with 86M and the share price > falls as if the sale had taken place -- but all holdings stay the > same: I still own 60%. > > It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but I can > "sell" another 10%, again gaining the market price of one share and dropping > the price further while giving up nothing. (The "Game Report" > window does not reflect the Undo so maybe that is a no-op here.) > > (A possibly related annoyance I found earlier: If Marcus wants to sell some of > his 15% holding of PR, the interface allows him to sell either his 5% certificate > or his 10% cert, but not both at the same time. I can sell one at a time, but > this causes the price to fall twice, which is not possible under the rules of > 1835.) |
|
From: Erik V. <eri...@xs...> - 2011-11-20 20:11:57
|
> From: Stefan Frey [mailto:ste...@we...] > B) Player T3 sells 30% of WT: There is no selection to chosse either one 20% > or two 10% certificates for exchange of the president certificate. Not sure if this was an accidental or a deliberate oversight, but in any case the current share selling process was not prepared at all to allow such a choice. It's now overhauled to allow a selection of exchange certificates in case of a dump. In all dump cases (in all games) the exchange certs are now mentioned as well. Where a choice is possible, the selling choice list has separate options to cover the different exchange certs. > From: John David Galt [mailto:jd...@di...] > This save file is a later one from the same game, and shows an amusing > stock-market bug. > > At the point of the save, John has three 20% certificates of OL. > If I click to sell some of them, the program offers to let me sell either one or > two 10% certificates, or one or two 20% certs, but not three 20% certs. (So > apparently the game engine "thinks" I have two 20% and two 10% certs, but > that is not possible -- with 30% still in the IPO, only one 10% cert has ever > been purchased.) Obviously, three 20% certificates can never be sold to the Pool. I don't know what caused the offer to sell one or two 10% certificates. Anyhow, this is no longer the case, probably because of the above fix. If another player had two 10% OL shares, one could argue that it would be allowed to sell 50%, because a president share exchange would be possible. This does not actually happen now. If Kent buys another 10% OL cert, John in his next turn still does not get another sell option after first selling 40%. Not sure if that is correct... > It gets even more interesting if I take the program up on its offer to let me > sell one 10% cert. When I do this, I am credited with 86M and the share price > falls as if the sale had taken place -- but all holdings stay the > same: I still own 60%. > > It gets still weirder if I "Forced Undo" the sale: Undo does nothing, but I can > "sell" another 10%, again gaining the market price of one share and dropping > the price further while giving up nothing. (The "Game Report" > window does not reflect the Undo so maybe that is a no-op here.) This all is no longer possible. > (A possibly related annoyance I found earlier: If Marcus wants to sell some of > his 15% holding of PR, the interface allows him to sell either his 5% certificate > or his 10% cert, but not both at the same time. I can sell one at a time, but > this causes the price to fall twice, which is not possible under the rules of > 1835.) It works fine for me - two subsequent sell actions at the same price. Erik. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X