Surprising 8 digit precision feature.

QCUser

This is just a heads up to save a headache for someone. The 'Extended share precision (8 digits vs. rounding to 6)' option in Quicken Classic has a surprising feature. If you transact a quantity is less than .000001, the Share Bal and Inv. Amt will be correct, but the lot transaction will have zero shares recorded. This will mean that in the Holdings window, the share balance is no longer the sum of the lot shares. I thought this was a bug, but tech support corrected my miss-perception and told me it was by design.

mshiggins

Humm. Seems like an odd thing to be by design.

Chris_QPW

Sounds like Quicken Support is covering up for a bug. As in the transaction dialog and maybe other places like the Holding window have not been properly updated for this option.

Example, with the 8-digit option on:

0.0000001 x 100,000,000 = 10, not zero.

Rocket J Squirrel

A Quicken file cannot have an entry that is larger than 99,999,999.99.

100,000,000 should have given you an error.

https://www.quicken.com/support/size-or-capacity-limitations-quicken-data-file

Chris_QPW

https://community.quicken.com/discussion/comment/20396174#Comment_20396174

Good point, my mistake there isn't a bug.

Look at this (showing the holdings):

So, it isn't that it can't show 8 digits of precision, it can. It is just that if you enter such a low amount of shares it gets into the category that you bump up against Quicken limits like @Rocket J Squirrel stated.

indiggio

Looks like in the latest release they totally broke the 8 significant digit feature.
I had been using it to track Bitcoin amounts and it had been working, but it just sent me an update and now when I go to add a new transaction with 8 digits and with the 8 digits preference set, it just reverts back to 0.
If I scroll past old transactions that had 8 digit share counts, it zeros them out and set the share balance to Italicized font.
I tried shutting down and restarting, hoping that that would clear the issue to no avail.
Thanks Quicken! 😡

UKR

Does anybody know if Quicken uses floating point arithmetic to make share calculations?
Remembering back to my days as programmer on IBM Mainframe computers, there's a possibility that extremely small or extremely large numbers, when represented in floating point notation, cannot be represented exactly when converted back to decimal digits and you only get estimated results, not precise to the penny ones.
Could this be the case in this situation?

Chris_QPW

@UKR Quicken Inc doesn't tell us such details, but my guess is that they are using C++ doubles/floating point numbers. At least I hope they and not using floats. Doubles are 64-bit and floats are 32-bit.

Doubles have 15 digits of decimal precision and basically line up with IEEE 754 Double Precision floating point standard. This is important because the floating-point processors use the IEEE 754 standard. (Floats have about 7 decimal digits of precision.)

So, I don't think this is the source of the problem. More likely what they are doing in the input routines, (rounding).

Note that this number can't be represented accurately:

99,999,999.99999999 (8-digits after decimal point, because it is more than 15 digits overall (16)).

Whereas this one can: .999999999999999 (exactly 15 digits)

In both C/C++ and IEEE754 numbers there are three parts. The sign, the exponent, and then mantissa. In general, it is the mantissa that you are worried about when talking about the precision. Since the digits can be moved to the right decimal place by the exponent.

You also have to careful on how you do the math so that you don't lose precision with ever calculation. There is also what are you going to display/allow for entry which might be constrained by the size of your text box or other requirements.

And there is the rub. There is absolutely no standard with the brokerages of how to round the number of shares. I have even seen some brokerages send shares rounded to 6 digits for Quicken and use 8 digits on their website, and that might not be what they would do internally in their financial database. This is how you can get Quicken telling you that there are fractional shares still in Quicken, but you can't see them. And you will get complaints from users when the are rounded differently.

The one BIG thing that a programmer should never do with floating-point numbers is:

if myDouble == thatDouble

{

}

myDouble = 1.0000000000000

thatDouble = 1.0000000000001

Whenever comparing floating-point numbers, one has to keep in might what precision is needed for that decision.

Rocket J Squirrel

You also have to careful on how you do the math so that you don't lose precision with every calculation.

This was probably the first thing they taught us in freshman computer science class.

Imagine you have a formula with multiplication and division:

a = b / c * d

If you perform this left to right,

a = (b / c) * d

you may lose precision because division is not always precise and then you're multiplying the error. Better to perform this as

a = (b * d) / c

which may not be obvious to someone who missed that day in freshman comp sci class.

q_lurker

@Rocket J Squirrel

I think in several cases that is exactly (or almost exactly) where Quicken does get caught. I am thinking of a parallel conversation here related to stock splits. I suspect Quicken quickly converts to or takes in as user input a limited precision decimal (b / c) = Ratio, and then Ratio gets carried forward for subsequent calculations. Even in the Mutual Fund Conversion where they prompt for Shares Received, I suspect it becomes Shares Received / Shares Owned = Ratio, and then every lot gets that Ratio applied to each lot. Trimming cost basis for partial lot sales is another place where cents can slip away. But as @Chris_QPW observed, the brokerages can also take varied approaches.