Why does the basis of all of my money market funds eventually erode to slightly less than $1.00?

Dennis Goldstein

Why does the basis of all of my money market funds eventually erode to slightly less than $1.00? Every transaction is at $1.00, but the basis erosion eventually happens with every money market fund. I can usually trace it to a particular buy transaction. But even though the purchase is shown as $1.00, I cannot correct the basis erosion? Any suggestions?

Jim_Harman

Are you looking at the Cost Basis column in a portfolio view to see the cost basis, or someplace else?

Are there placeholders or Added or Reinvest transactions for the money market funds? Those can mess with your cost basis. Sometimes Added or Reinvest transactions are erroneously downloaded with a cost basis of 0.00. 

Dennis Goldstein

I am looking at Portfolio view. I have checked and rechecked. No transaction is for less than $1.00. And this happens with every fund where the price is always recorded as $1.00.

Dennis Goldstein

I had one money market fund with a $1.00 basis. Yesterday I entered a buy at $1.00 and the basis slipped to $0.999999. This has been plaguing me for years.

Rocket J Squirrel

I have 3 money market funds, and this happened to one of them (FCFXX). The cost basis per share shows 0.999999. For reasons lost to history, this was the only one of my MMs that was set to "average cost". So I can only imagine it's actually performing the averaging and getting roundoff error due to arithmetic division - despite the fact that I have only 1 lot of this MM (dividends not reinvested). Changing the MM to not be average cost did not repair the rounding, and neither did deleting the price history.

Jim_Harman

@Dennis Goldstein What column are you looking at in the Portfolio view? Is it Cost basis or Average cost per share? For a MM fund with a $1.00 share price, the Cost basis should always = the market value.

Try going to Edit > Preferences > Reports Only and set the Decimal places for prices and shares to 6. Then look at the Portfolio Value report. Do the number of shares for your MM funds have more than 2 decimal places? Is the cost basis reported there = the market value = the Balance?
 
Assuming you do not have the Use average cost option set and the share price is always 1, Cost basis should be calculated by addition and subtraction. As RJS notes, Average cost per share requires division, which could lead to rounding errors. 

garysmith87

Not sure if this helps or not...but I would uncheck the Download Quotes for that money market fund in the Security List section.  

I had this happen a while ago, and since I unchecked that, it seems to have corrected itself.

Also, one other thing you might check is the Edit Price History for that fund.  Sometimes a wayward price just less than $1 gets downloaded.

As I said, this might or might not fix the problem...but it's easy to check and rule out if that's the issue. 

Dennis Goldstein

The column with the issue is the "average cost per share." The "market value" and the "cost basis" agree at $1.00 per share value, but the "average cost per share" is wrong. None of the money market funds are set to download prices; I went to 6 decimals, but no change appeared. In the past I have seen considerable erosion in money market "average cost per share" and I don't know how this impacts Quicken's calculations.

Chris_QPW

Dennis Goldstein said:

The column with the issue is the "average cost per share." The "market value" and the "cost basis" agree at $1.00 per share value, but the "average cost per share" is wrong. None of the money market funds are set to download prices; I went to 6 decimals, but no change appeared. In the past I have seen considerable erosion in money market "average cost per share" and I don't know how this impacts Quicken's calculations.

I would check the price history and see if there is any amount in there other than $1.

Rocket J Squirrel

My theory was that using "Average Cost" (like FCFXX below) was invoking a division operation, resulting in rounding error. This seems not to be the case, as I have one MM security not using Average Cost and still rounding badly. Price history is all 1.00. So I have no explanation. But I don't concern myself with an error in the 6th decimal place.

Dennis Goldstein

There are no buy, sell, or reinvest transactions at less than or more than $1.00.

Dennis Goldstein

In the past I have seen erosion reaching the second decimal place. I don't yet have that with my current money market funds, but over time, I expect that will happen again. Thanks for your efforts.

Chris_QPW

I have seen this in the past and I thought I tracked it to a bad price in the history, but I can't be sure, and I don't see it any more in my one "cash mutual fund".  It was never much of a big deal to me given that I never had and real need for it to be correct.

q_lurker

I gather you are talking only about this erosion only in the column highlighted.


The associated columns for Shares, Cost Basis and Mkt Value agree with each other.  If that is the case, I would not worry about it.  I would attribute it to a round off.  I believe that column is computed on the fly for that portfolio view direct presentation.  I have no reason to believe it is used anywhere else for any purpose.

That is not to say that X / Y = 0.999999 (same round-off error) doesn't occur somewhere else in some other calculation, but if so, it would need to be judged in the context of that calculation.

Now the fact that you have seen this erosion 'accumulate' or take on greater significance is a bit concerning, but that too would need to be looked in in specifics.

Clearly, in my four MM fund situations today, I am not seeing that type of error.  If I toggle the As Of date (not shown above) through time, I do find the 0.999999 value on at least two of the funds for various values, even though Cost and Shares match exactly.

A Checkpoint -- A MM fund with 3,173.72 shares, cost, and Mkt Value yields the 0.999999 Avg Cost/share.  Change it by 0.01 either way and the Avg Cost/share come to a true 1.0.  Any confirmation from others?  That seems to me to directly categorize this as a computer math precision issue.

Chris_QPW

q_lurker said:

A Checkpoint -- A MM fund with 3,173.72 shares, cost, and Mkt Value yields the 0.999999 Avg Cost/share.  Change it by 0.01 either way and the Avg Cost/share come to a true 1.0.  Any confirmation from others?  That seems to me to directly categorize this as a computer math precision issue.

Very interesting!

I did a buy of just enough shares to get 3.173.72, and I see the same thing:

Jim_Harman

I get the same result with just one Buy in the fund. It does not matter if I specify the total cost or the cost per share.

It is hard to see how X/X could = anything other than 1.000000. Experimenting in Excel, I have to make the denominator 3173.722 before the result rounds to 0.999999.

Dennis Goldstein

After reading through the comments of all, I revisited the last buy transaction of $1,455.77 which had caused the cost per share to erode. On a pure hunch, I changed it to $1,455.00 (no cents) and the cost per share reverted to $1.00. I then changed it back to $1,455.77 and the cost per share again eroded to $0.999999. Does this give anybody a further clue? I certainly don't understand what is going on here. But as long as it stays in the fifth and sixth decimal points, I guess it's not really a problem.

As @Jim_Harman well put it, it is hard to see why X/X could = anything but 1. Also, it seems like the denominator there should have to increase as the cumulative sum of historical purchases increases.

Chris_QPW

Dennis Goldstein said:

Does this give anybody a further clue? I certainly don't understand what is going on here. 

Given that Quicken is trying to round to 6 digits after the decimal point, and that is exactly where you start seeing the problem I'm pretty sure the problem is in the way the developers are doing their rounding.

Jim_Harman

More data points: If I multiply or divide the amounts by 10, the share price is $10.00 or $0.10.

But if I multiply the total cost by 2 to $6,267.44, the average share price shows as $1.999999, so the issue appears to be someplace in the rounding of the binary representations of the numbers.

Rocket J Squirrel

Now I want a peek at the code. Maybe they're using double and switching to long double would fix it with a recompile. 

Chris_QPW

Rocket J Squirrel said:

Now I want a peek at the code. Maybe they're using double and switching to long double would fix it with a recompile. 

A double has a precision of about 14 digits, so that really shouldn't be it.
And they really shouldn't be using "binary numbers".

It is very true that when you convert between two different bases like decimal to binary there are going to be fractional numbers that can't be represented accurately.  It is the same thing as if I go from fractions to decimal fractions.  Like 1/3 is exact, but in decimal you have .333333333333... so it isn't exact.

But doubles aren't stored as fractions.  They are stored as a integer mantissa with an exponent for moving the decimal point to where it needs to be.

And up to how big a number the mantissa can represent there isn't any difference between the decimal and binary notations.
From Wikipedia


52 bits can accurately show numbers up to this amount (with the decimal point shifted +/- 1024 with the exponent).


But one strong possibility is that they are using a float instead of a double, but with that I would expect it to be wrong much more often.  A float is similarly stored like the double with the sign, exponent, and fraction/integer part, but instead of 64 bits it is stored in 32 bits.  Note "float" is just C/C++ term for "single precision floating point number", and double is "double precision floating point number".

q_lurker

Some other values -- Not that I expect anyone to identify a pattern
2,570.43
73,696.93
73,902.79
187,435.80
I am reminded that Quicken needs to handle both the cost and the shares to 99,999,999.99.  The single, double, float, whatever precision needs to be accurate to that large of a value.

At this point, I hope others also see this as an academic exercise.  That there is no meaningful issue to the 0.999999 vs 1.0.  Though I do find myself wondering why it is not ever 1.000001

Chris_QPW

I'm not that great at math, but as I look at this I think that we are actually looking an a "mathematical interaction".

Look at this:




Is started playing around with numbers to see how they were doing the rounding, and then I noticed something.  For the number of shares you can have up to 6 digits after the decimal point, the same for the price paid, but not the total cost, it is restricted to two digits.

That restriction means that you aren't dealing with all the numbers out to the same precision.

q_lurker said:

Though I do find myself wondering why it is not ever 1.000001

How about this:




Not exactly what you asked for, but close!

q_lurker

On buying the 2570.43 shares, one can use prices from 1.000002 to 1.000005 and all four prices yield a total cost that rounds to 2570.44 (2,750.4351... to 2,750.4428...).  We have expounded to new users for years that the price per share is not critical.  Don't worry about it.  

Here (your example), Quicken then turns around and computes $2,570.44 / 2,570.43 shares as $1.000004/share.  Carried to more precision, 1.00000389... which it rounds to 1.000004.  Nothing at all wrong with that.  It is immaterial that your purchase price entered was 2, 3, 4, or 5 in the last digit.  Quicken is computing and showing 1.000004 correctly based on price to the penny and shares to the hundredth (in this case). 

The math is not Shares * price/share / Shares.  As you noted, it is ROUND(Shares * price/share, 2) / Shares.  So why is $2570.43 / 2570.43 shares not 1.000000?   So asked the CS 102 professor.  Or was it a GTA?

Following up on the thought from @Jim_Harman,
2,570.43 shares bought for $2570.43 turns to 0.999999. 
At $5,140.86 >> 1.999999;
at $7,711.29 comes to $3 even. 
at $10,281.72 >> 3.999999.

Could they be dealing with integer pennies throughout, and then dividing by 100 to show dollars and cents visually?  Here we then see some nuance of mixed integer / real computer division?

Chris_QPW

Well I will say that there is something a bit special about these numbers.
In the Visual Studio IDE, pointing at the variable:


So as you can see it isn't "exactly" represented if you take it out enough digits.
But neither is pretty much any fraction, it just depends on the rounding.


But in truth this should never matter, because the two numbers should be the same and therefore always divide out to 1, at least to beyond 6 digits past the decimal.


I have no idea what they are doing with the numbers to come up with what happens.

One more piece of information, this isn't anything new, I tied in Quicken 2013 and got the same result.

Chris_QPW

BTW @q_lurker I know my example with the use of price paid and such "isn't the same", but the point was that the cost is two digits after the decimal point and the shares are 6 and there might be some kind of interaction between the two with them trying to round to different number of decimal places.

Whatever they are doing I can't figure it out, because with any reasonable amount of rounding the numbers above should always calculate out to 1.

Dennis Goldstein

This was an interesting discussion; some of the coding and math is somewhat over my head. But, I am not certain that rounding is the problem. I have a second money market fund (SPAXX) that has now eroded to an average cost per share of $0.999961. Furthermore, I am certain that other funds I have held in the past (but no longer hold) have shown even more erosion in this column.

Chris_QPW

Without seeing the code it is really impossible to tell what they are doing, but this still can be a "rounding error".  When you have multiple lots you will have the math repeated over and over, if you make a mistake in how you do it and are off by even a little bit it will add up over time.

q_lurker

Dennis Goldstein said:

This was an interesting discussion; some of the coding and math is somewhat over my head. But, I am not certain that rounding is the problem. I have a second money market fund (SPAXX) that has now eroded to an average cost per share of $0.999961. Furthermore, I am certain that other funds I have held in the past (but no longer hold) have shown even more erosion in this column.

Since you now have a specific significant (0.999961) erosion to investigate, I would:
a)  Group that portfolio view by Account
b)  Review if the degradation is common to all accounts or more specific to one or more accounts.  (I am assuming here that you own this MM in more than one account.)  Likewise, are all accounts showing consistency across Cost Basis, Market Value, and Shares.
c)  While I would expand the view for each account to show each lot (click + next to security), I doubt that will be particularly revealing.
d)  I would vary the latest transaction by $0.01 = 0.01 shares to see how the specific value affected the presented Ave Cost per share.

If you are willing, if you could share the cost, share totals that are yielding the 0.999961 value, it might be illuminating.  (Is it a big number that does that or a little number?)
   

Dennis Goldstein

At this time, I hold small amounts of these shares in two accounts. In one account the average cost per share is $1.00; in the other it is $0.999552. I increased the last transaction in the latter account by $.01 ( = .01 shares) and it made no difference in the average cost per share. Decreasing it by the same amount also produced no change. In this account, the total balance is now only $156.37, the average cost per share is $0.999552, and it shows a cost basis of only $156.30 and a "gain" of $0.07. I checked again and there are no buys, sells or reinvestments at anything but $1.00 precisely.

Very odd, at least to me.