S'pose?

For the record, another way to do this is the way that COBOL did it: "packed decimal," otherwise known as "BCD = Binary Coded Decimal."

In this representation, groups of 4 bits (i.e. hexadecimal digits ...) represent decimal digits. The rightmost 4-bit group represents the sign of the number, using one of the six bit-patterns that are not $0 through $9. So, for example, in a 32-bit word, you could store 7 digits plus the sign.

Even the lowliest microprocessors support a decimal mode.

There's another fundamental reason why computer floating-point numbers are not a good choice for dollars-and-cents calculation: the exponent of the number is actually base-two, not base-ten. Just as it is impossible to precisely represent "1/3" in decimal ("0.3333..."), it is for the same reason impossible to precisely represent "1/10" in a float-binary.

Although the differences are very small, one must always remember that "an accountant is someone who'll spend a dollar to find a dime."

It has been ground into their heads ... and into the heads of "failed accountants" who therefore Go To The Dark Side, becoming regulators and tax-officials ... that "the books must balance 'to the penny.'" Woe be it to anyone who doesn't pay careful attention to that.

You're putting in an awful lot of horsepower into analyzing this particular issue, you've found that single precision floating point will not suffice. Eventually if the numbers get large enough, double precision will no longer suffice. You have a ton of open issues related to tracking information related to your finances. I'd stick a fork in the whole math subject by ensuring that you have financial calculations which are rock solid via integer conversion. Consider also that I do not believe you are calculating fractional results either, correct? You are taking the results reported which are numbers from statements, even if the transaction resulted in fees or earnings which were expressed in lengthy percentages like 2.9995%, the statements you receive and the actual amounts given are already rounded and so you would either receive $0.02 on one dollar, or $0.03 on one dollar. Or in fact if it involved $1000.00 then the 2.9995% would mean that you would receive either $29.99 or $30.00, but that number would be in the statement and while you might validate that their calculations were close, you would also have the exact figures which they gave to you. If that point were in error, you could raise it there. And then if they don't help you calculate the total gain or loss, you could report it properly on your own.

I think it's two parts (1) validating that each individual report is as accurate and complete as it needs to be, and (2) determining how you report your total status for your taxes. Because after all, per your example of buying, selling, buying again and finally re-selling. You could execute the two purchases using different brokers, correct? So it would be up to you to ensure your summary of reporting were correct, and also individually ensure that each broker house reported the individual transactions correctly.

It used to be that each individual indiviually figured out his gains
and losses. The thing that changed was what the Brokers had to report
to the IRS. That changed about 3 years into the Obama administration.
Now Brokers are supposed to report these disallowed losses. The
problem seems to be that programmers can't write the code to actually
figure it out, so they are reporting garbage to the IRS, and if you
use the broker's figures, you can get hosed. I went through this
last year at tax time, I had broker reports showing tens of thousands
of disallowed losses, therefore my tax was increased thousands if I
let them get away with it. I gave detailed accounts of each situation
to my tax prepare person and they would then report on the form what
the broker said, law required it, then make another entry wiping
out the disallowed BS and included my worksheet showing all transactions.

It is pretty surprising to me the accuracy of the calculations from
the broker. I have 3 brokers right now, and one just yesterday, had
a situation where they made a correction of plus $75 to my account
for a shortage they had made before, and I had sold some options and
received $4840.71 from that.

So I just received 75 + 4870.71, and they reported my new cash balance
as 115,576.94.

My cash balance before these things was 110,661.24. So do this addition,

110,661.24
__4,840.71
_____75.00
-----------

do you get 115,576.94. My computer doing that math gets one cent
more, and this was from just making two additions.

The problem is really not the one cent error, the problem
is the additional requirements the IRS has put into regulation
on reporting of gains and losses by brokers. There is actually
a cottage industry springing up to overcome this BS the IRS is
putting onto us. Some are selling programs that keep these
figures straight and then print a correct 8949 form for you
at tax time.

Believe me, I know how to get around all the crap the IRS puts
out, but it does make life more complicated.

Also, I think it makes the tax calculations so hard, that
auditors are probably going to go nuts trying to keep up
with their own rules. Making things this complex, and then
having to go through mounds of this crap in an audit must
make auditors life hell. I got nothing against making IRS
auditors life hell, so let the fun continue.

Ah yes, COBOL, I have not heard that name in years.
My first job as a programmer was as a COBOL programmer.
In those days over 90 percent of programmer jobs was in COBOL.

I was in a community college majoring in computer science,
I recently retired from the Air Force, my wife, a nurse had
gone into the army and we were stationed at Fort Dix.
I stayed home and took care of the kids and she went to
work. For entertainment I enrolled in college and took
up computers. I had the highest average of all the guys
in the computer science area and I was about half way
through COBOL, when the college wanted to higher a
part time programmer, all their applications were in
COBOL. My instructor recommended me to the computer
department, and I had my first computer job. It was
pretty entertaining.

That was in 1979 or 80. How times change, I never
hear of COBOL now, and I have programmed in 15 languages
since that day.

Retired in about 2003, but still program some for my own
use and entertainment.

This thread illustrates why Cobol (COmmon Business-Oriented Language) always uses integer math in the base language, no need to add library functions or jump through coding hoops.

There were at least 3 ways to represent numbers within a Cobol program: display (PIC 9), binary, (either litlle- or big-endian) and packed decimal, all computations would convert fractions to integers automatically.

Well, to be fair, the IEEE's floating point standard wasn't around when COBOL was designed.

Correct me if I'm wrong, but I think Fortran is about as old as Cobol, and used its own floating point numeric, not unlike IEEE. Before C, it was: Fortran for scientific programs, Cobol for business.

yeh, Fortran is probably as old as COBOL, I am guessing older. I don't
remember that much about it's number types though, never did like the
language much, but got stuck with it in one of my main jobs for about 12
years. Never did learn to like it.

Fortron = 1957
COBOL = 1959

Both quite old and outdated now.

Indeed, fortran is quite outdated: standard fortran2015 isn't defined yet, we have to use fortran2008; cobol is a bit better, it has version cobol2014
https://en.wikipedia.org/wiki/Fortran#Fortran_2008
https://en.wikipedia.org/wiki/COBOL#COBOL_2014

Just because there are modern standards out doesn't mean the language isn't outdated for the most part. How much software do you see written in Fortran or COBOL in the wild?

For example, right here in this Forum fortran-related question do come up regularly.

Every day. Fortran is very much alive and well in the scientific community.

Using a spreadsheet is much easier than a C program for the original problem.
In a C program doing personal accounting, double is the best data type. float is simply not accurate enough. double is accurate enough and simple and efficient to use. Anything more accurate than double requires significant extra effort by the programmer.

If you were coding the securities portfolio analysis for financial institutions (something I actually did in the distant past) you would certainly not use double. You would select a data type that will provably be accurate to the penny on absurdly large computations every time.

Even in home accounting, it is harder than you might expect to prove that every computation in your home accounting algorithms will be correct to the penny. double has enough precision for the amounts to be correct to the penny. But provably correct is harder. As an active investor, who keeps duplicate records and compares to brokerage records (rather than trusting brokerage records) I know that "usually correct to the penny" is an important standard for home accounting for those few of us who make such comparisons. But "always correct to the penny" is a completely pointless goal. The brokerage is NOT always correct to the penny. Part of comparing is adjusting my records to match their records when they are off by a penny. That is one of the things easier in a spreadsheet than in a C program:

Example: company X spins off company Y at 1 for 8. I had 50 shares of company X, so I get 6.25 shares of company Y. My broker automatically merges my .25 shares of Y with fractional shares of all their other customers in similar situations and sells those whole shares and proportionally distributes that cash. Now my cost basis for X has been split into 3 parts: Part is remaining reduced cost basis for X, which will matter someday when I sell those shares. Part is cost basis for my 6 shares of Y. Part is cost basis for the sale of .25 shares of Y. There is a legally specified formula for computing those three numbers and I plug that into my spreadsheet. Then my brokerage account shows their 3 numbers, one is a penny high and two are each a penny low. So one cent of cost basis has vanished entirely, and the gain on the fractional share is one cent higher than it really was. That is just an annoyance of investing. Comparison is to find the brokerage's big errors. They make little errors and you just fix your records to duplicate their little errors.

In my experience, having had to maintain that crap on several occasions, I can confirm "alive" and contest "well". Fortran is mostly used by stubborn non programmers who write terrible code, both because they aren't programmers and because it is a terrible language. But there is too much cultural inertia to throw it out and use easier languages for the small projects and C++ for the big projects. (C++ is very flawed. But every other language in common use for big projects, very much including Fortran, is so unsuited to big projects that its continued use is insane).

http://t.co/dZwke4cmnS



The other thing to be aware of when using floating point numbers is that comparing them for equality is more complex.