I no longer use Twitter, so I'd prefer to direct traffic to LinkedIn where I am more active.

VECROSS was written for the same reason as ELECCONS, to simplify the
work I had to do during my university physics homework and exams.

This program was particularly helpful since the cross product formula
seemed like a random jumble of computations since I hadn't learned its
relationship with linear algebra.

This is a less nefarious version of the LOADING program that I wrote
later in my high school career. Like LOADING, I would find a moment on
a friend's birthday to steal his/her calculator and copy the program
over. I'd then usally open the PRGM menu so that the next thing my
friend saw was the word SURPRISE on their screen. I always had fun
seeing their smiles as they saw the HAPPY BIRTHDAY! animation. Even
better was the fact that they immediately knew it was from me since I
was the only one that knew how to program the calculator :D

Well, here's the first computer game I ever made: an extremely verbose
Rock, Paper, Scissors game! I remember being especially proud of the
"PLAY AGAIN?" menu.

I don't remember when I wrote this program in relation to the others in
this repository.

Here's what each program does:
* **PRCNTDIF** - PeRCeNT DIFference
* **PRCNTERR** - PeRCeNT ERRor

These two programs were written during my college prep physics class
during high school. They are a classic example of using my calculator
programming skills to avoid learning the rationale behind an
important formula for experiments. I simply didn't want to have to
worry about the formula, so I figured it out once and then let my
calculator take care of it from thereon and thenceforth.

However, though they are only three lines long, they demonstrate one
interesting insight into my development as a programmer. These programs
appears to be the first time that I did computation in the `Disp`lay
step in order to save a line or two of code. It demonstrates that (1) I
had started to figure out the expanded set of precedence rules that
govern expression evaluation in programming languages and (2) had begun
to exploit those rules to make my programs more concise and readable.

Here's what each program does:
* **PHEDLA** - PolyHEDron Lateral Area
* **PHEDSA** - PolyHEDron Surface Area
* **PHEDVOL** - PolyHEDron VOLume
* **POLYAREA** - POLYgon AREA
* **POLYPERM** - POLYgon PERiMeter

The year after writing QUADFORM I started taking geometry in high
school. I was excited about my ability to encode math formulas in my
calculator, so instead of memorizing all the geometry formulas (much
less understand where the numbers in them come from), I wrote a set of
programs to calculate everything for me.

Since there were so many formulas, I decided to group them into five
programs and use a menu system to select which calculation to do. These
were definitely my first menu-based program and the first time I
demonstrated an understanding of the value of grouping similar pieces
of functionality together. #modularity

This program clearly has some parallels to middle block of FACTOR
that shows a "CALCULATING..." animation when the numbers to factor are
large.

I know that the first version of FACTOR definitely preceded LOADING,
but I don't remember if I added the "CALCULATING..." animation before
or after writing this program.

As a goofy high school student, I had fun pranking my friends with this
program. When they weren't looking, I used a link cable to copy this
program to their calculator and start it up. When they got back, they
just saw their calculator in a long LOADING animation. Even better,
since the TI calculators have a slow clock speed, this program would
run for a long time, causing my friends to get super frustrated that
their calculator was "unusable" for so long! (Of course I didn't tell
them that pressing the ON button would kill the program).

ELECCONS was a simple program I wrote during my University Physics
course. There were lots of constants used throughout the course, and I
got tired of typing them into the calculator. This program simply
assigns those common constants to variables so that I could use the
letters in my calculations instead of the big long numbers.

I don't remember what all the constants are right now, though I could
probably cross reference with my physics notebook to figure them out
again (or just look up the numbers, they are probably easy enough to
find that way).

This program was written to make life easier for one specific
probability assignment. We had to roll four dice a bunch of times,
keeping track of the average of the dice for each roll, as well as the
total times that each number was rolled.

While not a challenging assignment, I found it really tedious, so
instead of rolling dice, I threw this program together and used it to
do most of the work for me instead. :P

I wrote the first version of this program the summer after writing
QUADFORM. I worked on it on and off for a few months, often drawing out
pictures of the "box method" for factoring a quadratic equation to
guide my design. Those drawings constituted the first time I had truly
solved the general case of a math problem, which certainly prepared me
for learning proofs in geometry the following year (though I didn't
recognize it at the time).

When the program was finally done, I felt so proud of myself! This
particular program won me lots of attention from fellow classmates and
even from a few future teachers. It likely saved me enough time on
homework and exams to compensate for the time I invested into writing
it.

Since I used this program so much, I gradually added additional
enhancements. For example, when factoring an equation with large
coefficients, the factoring computation got pretty slow, so I added in
a "CALCULATING..." animation so I would know that the program hadn't
frozen.* Later, I added a few extra checks like the a+bi mode and
computing the discriminant to further improve performance and the user
experience.

* I now know that the long computation times for finding factors stem
from an inherent complexity in that problem. In fact, it is that very
computation difficulty which makes prime number factorization so
desirable for most modern encryption techniques.