
IB_YTD_ANAL PROGRAM TO ANALYZE INTERACTIVE BROKERS YTD FILE TRADES

Release 1.20 of 03/06/26

This is a program called ib_ytd_anal to analyze downloaded
Interactive Brokers (IB) year to date .csv spread sheet files.
I run it each day to see total return, potential option
and dividend income and to see what has worked and what
has not.  Program scrubs the Interactive Brokers
"Year to Date" .csv file.

Idea of ib_ytd_anal is that it will be used by
people that have some C computer language programming skill
(or groups that have C programmers).

Make your own changes for things you want to see.

I will make new releases and am working on setting.
Idea is that you deal with new versions either yours
or other peoples by using file diff programs and merging
in the code segments from each version you want.
I user either standard diff or vimdiff side by side windows.
I keep changing my mind what I want to see so I change 
ib_ytd_anal.  Idea is that repository checking in and
checking out is too hierarchical and too susceptible
to office politics.

To compile ib_ytd_anal program, type: 
make -f makefile.ib clean (optional)
make -f makefile.ib

Then type: 

ib_ytd_anal <name of today's IB YTD downloaded .csv file>
(.csv file will probably be named something like
UXXXXXXX_20250101_20251114.csv).  I then rename the output
ib_ytd_anal.log file to something like
"log.<mth-day>.<name of day of week>.<year>".

Before starting you will need to add a description
line for each position open from the previous year.
Add the line to the "static void bld_prev_yr_d1_trans(void)"
proc in the ib_ytd_anal.c file.  There are a few
commented out examples in the file.

I suggest that using ib_ytd_anal is much easier,
more flexible and more portable than coding complicated
spread sheets with needed spread sheet unportable (usually)
macros

This is part of my effort to falsify the very idea of AI
following James Lighthill's 1970s Lighthill Report
thinking.  The philosophical arguments are on my
substack blog.

https://substack.com/@sjmeyerfalsifyai


ROLE OF A COMPLETELY CHANGEABLE PROGRAM IN MY FALSIFICATION OF AI

In my Feb. 4 "No Need for Data Centers - LLMs can't get any better"
substack post (https://substack.com/home/post/p-186913599),
I refer to Gary Marcus arguments against LLMs.   

One reason for providing ib_ytd_anal is to answer criticism
of Marcus saying he does not know anything about programming.
I am suggesting that simple flexible C computer language
programs are much better than LLM generated programs. 

Problem with using LLMs for programming (you could run a
LLM next token prediction algorithm on your custom c code)
is that following Marcus LLM decompose and then rebuild text.
Result may be good or it might be hallucinations (called AI slop).
At best, programmers need to read the LLM generated AI code
that certainly will take more effort than just writing the code.
LLM AI program generation is just the old failed "automatic"
computer program generators of the late 1990s with better PR.
At best, you will need to make sure the LLM reconstruction
does not contain hallucinations. Process will certainly take longer
and be less reusable than just writing code (or modifying some
code you have already written).

Here is a Reddit criticism of Marcus argument with title "Marcus
is not an AI Expert."  

"Gary Marcus is an entrepreneur who uses his legitimate titles in
neuroscience to drum up a public appearance of self importance
in a field he knows nothing about. He's produced absolutely zero
production software, designed zero neural network technology,
submitted nothing on GitHub, and everywhere his name lands he
can be seen constantly preening his image - the sign of the
guy who pays others to make themselves look legitimate. He is
a speculative futurist at best and the two companies he co-founded,
his role was not in AI development whatsoever. Name one repository
he's developed that others use or cite in actual production
software, name anything he's made whatsoever that wasn't a book
about his own opinion."

Ref:
https://www.reddit.com/r/singularity/comments/1931eyy/gary_marcus_is_not_an_ai_expert/

Corporate software development that takes large teams
with many layers of management is so bad and so politics laden
that program generators may be better than that.
ib_ytd_anal simple one include file no classes and special
purpose libraries program organization is much better.

The thinking behind ib_ytd_anal program organization goes back to
the method (science of war) Dwight Eisenhower used defeat very
good German soldiers in North Africa at the start of US
involvement in WWII (documented in his book "Crusade in Europe").
AI lacks flexibility.  Eisenhower's method was make military
units flexible.  Add newly arriving soldiers to these flexible
units and then adopt and repeat and promote good results.
Then once the methods were found, organize units for mass action.
The German blitzkrieg tactics were too regular and too difficult
to change to meet unexpected situations.
Eisenhower also had increasing supplies that were part of
the method.

Idea of ib_ytd_anal is to provide a report that lets you look for
patterns (maybe by adding some indices) and seeing each day what works
and what does not without needing external data in addition too the
IB year to date report in .csv format.

Hopefully the simple ib_ytd_anal organization will prove useful
in other applications.

NOTES:

To RUN IB_YTD_ANAL PROGRAM:
1. You Must Change a proc to Call Procs that define Open Jan. 1 Positions

There is a proc at about line 2092 called bld_prev_yr_d1_trans 
that needs a call to add_cross_yr_op_1st_day_trans that sets
a table that tells ib_ytd_anal what positions are open across
the end of last year (see below for why ib_ytd_anal
only has year to date analysis).  You need to replace
my cross year open positions with yours. I have left in the
source some commented out examples of cross year calls.  I now
think having so many positions open across year boundary is a
trading mistake.

2. You May Need to Update the __smult proc for your Instruments 

Mostly for futures, you need to modify the __smult proc
at about line 407 in ib_stmt_ms.c file to add entries
for future contract multipliers for futures that I have not used
or are newly introduced.  Idea is to have a simple program that
does not need any data except the IB year to date statement 
downloaded .csv YTD file.

BEGINNING OF EACH YEAR CHANGES:
1. In addition to changing bld_prev_yr_d1_proc trans each year
you need to change a few 2025 literal years to 2026 (or current year).
Just grep for 2025 and ignore the Copyright notices.

LICENSING:
ib_Ytd_anal program is protected by Copyright.  You can
run it, but you are prohibited from selling ib_ytd_anal
without written permission (i.e. a legal license) from
Tachyon Design Automation.  Copyright normal fair use
rules obviously apply.

Below is the ib_ytd_anal program use license. 

/* === INSERT LICENSE ===
ib_ytd_anal program for analyzing Interactive Brokers format downloaded
Year to Date .csv format spread sheet file.

Copyright © 2005-2025 Tachyon Design Automation Corp.
All Rights reserved.  Licensed software subject to prohibitions and
restrictions.

The intent of this document is to state the conditions under which the
ib_ytd_anal trade analysis C program may be copied and executed such that
the Copyright Holder Tachyon Design Automation maintains distribution and
artistic control over the use and development as granted by Copyright law. 

Licensee may make modifications to ib_ytd_anal for internal use.  ib_ytd_anal
may not be sold without obtaining a sales license from Tachyon DA. 
All forms of indirect sales such as bundling or executing on a shared
cloud are prohibited.  Other uses of ib_ytd_anal program require written
permission from Tachyon Design Automation.

 DISCLAIMER OF WARRANTIES: THIS SOFTWARE IS PROVIDED "AS IS" AND
WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION,
THE IMPLIED WARRANTIES OF MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE,
OR NON-INFRINGEMENT.  THE COPYRIGHT HOLDER SHALL NOT BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING IN ANY WAY
OUT OF THE USE OF THE SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.

=== END INSERT === */

IB_YTD_ANAL PROGRAM ORGANIZATION

I think ib_ytd_anal has two data structure that are
easy to traverse to make computations and print output.
One is the transaction table (struct trans_t) and one is
the index of symbols (struct symndx_t) (really 2 
symbols - the base underlying symbol and the actual
instrument (option) symbol. 

Main function of ib_ytd_anal is to aggregate and output
trading history information.  ib_ytd_anal handles
open positions by adding a pseudo close record
at the end of each symndx record (sip->tr_ei).  This
allows analyzing open positions or all positions
depending on need of the tdy_pseudo_cl flag.

My thinking is that spread sheets are not programmable 
enough.  What is needed for people with basic C language
programming skills (C++ is useless because it requires
a large organization to deal with "supposed" general
classes and "abstraction").  There is one c .h
included file and just 3 not long .c source files.

IF YOU DO NOT HAVE AN INTERACTIVE BROKERS ACCOUNT

You can sign up for a paper trading account with IB.  The
paper trading account YTD .csv statement is same format
as the trading account file.  You need to make some paper
trades to see ib_ytd_anal function.

SPEEDING UP IB_YTD_ANAL TRANSACTION AND INDEX PROCESSING

The data structures in ib_ytd_anal program are simple and
slow.  Transaction processing can be speeded up by at least
a factor of a few hundred (maybe more) by searching by using
KARP-RABIN (Karp, R. M., & Rabin, M. O. (1987),
Efficient randomized pattern-matching algorithms. IBM J of
Research and Development, 31(2), 249–260) style hashing.
Not allocating memory for strings in the transaction and
symndx tables is slightly unportable and slower.

DEBUGGING:

To debug just set a gdb break point at proc __misc_terr
then use gdb up commands and print the *trp (names are always
similar) to see what the error is.

MERGING IN CHANGES
I use diff between old and new version source files and save
the diff output to figure out which code goes into new version.
For extensive changes i use vimdiff with two parallel windows.
vimdiff can diff 3 versions.

BUG FIXES
1. Release 1.20 has a serious bug in the code that decomposes
sells or buys that go from long to short (not 0) or short
to long fixed.  A number of sells from long to short code was
wrong.  If you downloaded 1.09, run diff between the two
ytd_ib_anal.c files to see the changes.

IMPROVEMENTS I AM WORKING ON, I.E BUGS

1. I need a options expiring nearest Friday list.

2. For some reason I do not make money trading ratio spreads
long one near the money option and short two further from
the money options).  I am writing a scanner that looks just
for my particular pattern of ratio spreads.  The programs
that try to analyze spreads in general lose too many details.
I also have a specific pattern I use for adding to spreads on
different days I need to aggregate.

3. Synthetic longs or shorts using long ATM call and short ATM put mash
option statistics.  You just need to adjust the statistics in your
reading of the daily ib_ytd_anal.log file output.  There is no
general way to deal with this.  Idea is that you need to
modify your private version of ib_ytd_anal for your trading patterns.
Then merge in your changes (or merge the other way).

WHY NO STATICS AND WHY ONLY YTD

I do not believe in probability theory past counting
dice or card type probability.  I grew up at Stanford 
where math/physics/CS majors curriculum was organized
by famous mathematician George Polya.  Polya did not
believe in probability theory because of his central
continuous random variable central limit theorem that shows all
continuous random variables converge to the normal distribution.
See Polya's 1930 central limit theorem for random variables.
We were taught the view from Apostol's calculus text
books (Apostol, T. "Calculus Vol. 2", pp 152-154). 

You may notice there is some unused (and not working) code 
for multiple year aggregated analysis.  I decided against
that approach.  I want to reset trading each year Jan. 1 so 
it makes sense to only see current YTD values.  If I want
to look more at a particular underlying, I open and look
at a previous year's file.

I find the for BAS all symbols (options) related to the base
symbols most useful.  Also the xdiv total table is valuable. 


BUGS:
1. If you include a position in the "bld_prev_yr_d1_trans(void)" proc
(table) with the wrong number of contracts, that wrong number
will be used resulting in slightly wrong values until the actual
number according to TWS is traded.  You will get an error
when "__fnd_posndx_oppos" proc returns a NULL possibly much later
in the year.  Best way to find this error is to make sure the BAS
values agree with your TWS open position lines.
