I was told back in the 80's I wouldn't have a calculator every where I go... well, guess what mother fuckers, I don't just have a calculator everywhere I go, but it's a full computer, a supercomputer by 1980's standards, and I literally make a living writing fucking software for it...

dicks.

It all began yesterday in my math lesson.My teacher introduced us into a new subject: The Heron method.
This is a method for iteratively computing the square root of a number which was made up by Hero of Alexandria.
But here's the cool part:
When my teacher said "method" I had the thought that I could make a programm on my TI-82 Stats (my calculator).
So I used the next break to make a little programm that does exactly the same what my mates has to do in several steps, in just one step.
Here is a picture so I can explain the programm:

First it asks for the root that it should calculate then for a value to begin with and finally for the amount of arithmetic operations.
Then it goes trough the algorithm and displays the interim results (this is important for later ...) .
So back in story.It wasn't surprising that we got exercises with this method as homework but through my programm I just needed 5 minutes instead of 20 minutes (like my class mates).

for your next edition of "TI's constantly been smoking crack since the 80s and has no intention of ever stopping":

the TI-8x calculators have a hardware buffer and an OS-provided buffer for screen data, effectively being an "immediate" buffer in hardware, to be displayed next VBlank, and a "slower" buffer, being what's copied to the "immediate" buffer when the OS decides it's time to update the screen. All well and good, maybe a little weirdly done but all in all makes sense. (You can even define a third buffer in RAM if you need to triple-buffer your shit.)

The problem arises when you use TI-BASIC and try to draw to the screen:
If you do something like, say, draw a circle, you'll notice that it's visibly drawn to the screen one pixel at a time. However, looking through what bits of the SDK I can find, the OS' "draw circle" assembly routine *doesn't update the immediate buffer!*

This means that, in TI-BASIC, the "draw circle" routine doesn't use the ACTUAL circle-drawing routine the OS provides, but instead individually calculates and plots a pixel, then updates the hardware buffer (an ENTIRE 768 bytes are copied EVERY TIME) and waits for VBlank to pass before repeating for the next one. In other words, it's deliberately slow as fuck.

Why? All the drawing commands, outside of like 2 or 3, do this. Why would you deliberately slow down the process of drawing to the screen on a system that you KNEW would be popular for people to code on???