First, I feel surprised that quantity of a stock, can be in floating point value.
(1) Is this requirement wished by majority of US investors, or this requirement is only needed by minority US investors? Can we consider this as edge case?
(2) Let's assume, this feature is really needed for US investor. For all the investors that I know, floating point in quantity is not what they expected. By allowing floating point in quantity, users will feel strange + surprised. So, how can we avoid users, who do not expect quantity to be floating point, from feeling surprised.
(3) If we change all the underlying data structure for unit, from int to double, how can we achieve backward compatible with old data files?
(1) I am not aware of how non-US trading is done, but here there is a form of trading account known as OMNIBUS (http://financial-dictionary.thefreedictionary.com/omnibus+account) in which a firm will combine share purchases from all account holders into a single purchase, with any fractional amount rounded up to the next whole unit value. The firm then "owns" that small remainder in their own house account. The rest of the purchase is divided up into each members' accounts.
There are many cases of this in the US. Many retirement accounts use this for example. Also, there is which provides this ability for many different account types and allows investors to purchase a specific dollar amount of a stock on a recurring basis. For example, you can setup a recurring EFT of some amount and when your account reaches some amount you've previously defined, it will purchase as many shares (including fractional shares) of that stock as it can for that amount.
I actually work for a financial services company that does separately managed accounts in an omnibus fashion. We regularly re-synchronize client's accounts to be in line with their investment objectives. Since these objectives are mapped to asset class percentage allocations which are then broken up into stock symbol allocation percentages (which our money managers can constantly update the percentages), the actual amount of any given stock owned by our clients has fractional units.
(2) Since a minimum and maximum number of decimal places can be defined on the number formatter, if we define the minimum as 0, then the user will not see decimal places for units unless they are entered. Thus, the user will only see what they expect to see.
(3) In my local environment, I made this change and my data that I entered prior to making the change worked flawlessly after the change. I did have to go back and edit my transactions to be correct now that I could. However, I did find that if I then went back to a JStock version without my change, my transactions disappeared and they did not reappear once I used my modified version again. This means that the modification is backwards compatible, but not downgradable to allow a user to revert to a prior version of JStock. Backing up the users existing data files during an installation would allow them to revert to a prior version should the new version not work for them.
I would also add that (at least for the US) that being able to handle fractional shares would be a requirement for any financial professional. The popular personal finances application Intuit's Quicken allows for fractional shares to be entered, as well as [ and .
(1) OK. It makes more sense now. But out of curiosity, may I know why some investors in US, like to combine their share purchase with others, into a single purchase?
(2) OK. This seems fine for me. We can have a options, to let user choose whether he would like share unit to be in floating point or integer. Can we have the follow?
If user choose to have integer format for share unit, Spinner Field will still be used as input field. **That it, after this feature be implemented, there will be no user experience change at all, for users who like to stick with "share unit in integer rule".**
If user choose to have floating point format for share unit, we will let them able to specific the number of decimal point as you suggested.
Hence, I would say these are changes needed overall.
(a) A JFormattedTextField, which we may specific number of decimal point
(b) Options field (Radio button?) to let user choose between integer or floating point. If floating point, have (JComboBox?) to let user choose number of decimal place. I suggest we rename the options tab, from "Advisor" (The one with light bub icon) to Portfolio. And add all the above options into that tab.
(C) Change of data type in all data structures.
(3) Fine. It is OK, if version 1.0.4 cannot read the file written by 1.0.5. However, 1.0.5 must able to read file written by 1.0.4
Overall, I would say "Yes", please help to implement this feature, and I am ready to accept code patch from you :)
However, there is an issues we may need to pay attention. If at first, user choose "floating point" feature, and his share unit is 1.23456. Then later, he wish to switch back to "integer" feature, so, what we should do then? My suggestion is that, our underlying data structure will still store the share unit as 1.23456, but we will display the unit as 1.
(1) It isn't a question of investor's preferences so much as how many brokerage firms work. The result to the investor is being able to purchase a specific $ amount of a share rather than a specific number of shares. This allows investors to use dollar cost averaging method of purchasing shares, resulting in regular purchases of a stock over time to average out ups and downs of purchase price as you purchase over time. Also, it allows investors to purchase a stock even when they may not have enough money to buy a full share. A very common example of this in the US is mutual funds. These have been around for decades and have allowed investors to pool their money to buy into stocks that are too expensive for them. Now, there are other options such as OMNIBUS brokerages and ETFs that provide similar advantages without the negative tax ramifications of a mutual fund.
(2) I'm not sure I see the need for the spinner control and it would add a lot of complexity to the application. The user would only see the precision they've defined, so if they define 0 decimal places for precision (integer), then the field will only show integer values. A spinner control doesn't seem useful as it's the only field that would have one and to use the control a user would have to switch from the keyboard to the mouse to enter a value. It seems more likely that a user would just tab to the units field and enter a value and then tab to the next field. I understand wanting to keep the interface simple, but I'm not sure the added complexity to the application of having the control for this field be dynamic in this way will actually simplify the UI. It's already a simple interface.
For now, how about I make these changes without the dynamic spinner control and send them to you? Then you can decide if you still feel the need for the spinner in this situation.
(3) The problem with your suggestion is that when you change the precision on an input field, the application will format the value in that input field to match that precision. When you click Ok, the application will see that the value has been changed (say from 1.23456 to 1) and will store the new value. Also, the Value and Net Value fields are calculated from this input field, so their values will be affected by this. Thus, if enter a purchase with a precision of 6 and then change the precision back to 0 and re-edit the purchase, you will loose the previously entered precision for that record. We can have different precision for the input field than we do for the portfolio display grid, but edits would be susceptible to problems. Generally, if a user defines a certain level of precision, it is unlikely that they will wish to lower that precision in the future. It would be a good idea to add a warning to the options screen for when a user drops their precision.
I'll work on this and send you my updates to try.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.