• like minded people can quickly vibe check and learn a lot about you
• easy way to share ideas and send them to friends
• written log of your thoughts and posts, adds credibility when someone has been writing about something for x amount of years
• can show off your taste, you control how every part of the website functions and looks (if you don't thats a skill issue) can express more than just words (the goat of this is gwern
• high variance low stakes. pretty low stakes and easy to set up a personal website (takes 1 hr MAX), but adds the possiblity for some pretty cool tail end events e.g meet a future good friend, job offer, etc. high expected value activity imo.

you can find a record of the best personal websites i have found here

before i dive into my hash table here are some of my FAVORITE Prolog quirks /s

"=" is different

% = is for unification, not assignment
X = 5.         % Unifies X with 5

% is is for arithmetic evaluation
Sum is 2 + 3.  % Evaluates 2 + 3 and unifies Sum with 5

% =:= for arithmetic equality
5 =:= 2 + 3.   % true
5 = 2 + 3.     % false! Because it doesnt evaluate 2 + 3

no loops, everything is recursive (this one is my least favorite)

print_numbers(0).
print_numbers(N) :-
    N > 0,
    write(N), nl,
    N1 is N - 1,
    print_numbers(N1).

negation as failure

% Let's define some simple facts
likes(john, pizza).
likes(mary, sushi).
likes(john, sushi).

% You might think this would work to find who doesn't like pizza:
find_pizza_hater(Person) :-
    \+ likes(Person, pizza). % "\+" is the negation operator

% But this fails:
% ?- find_pizza_hater(mary).
% false    <-- confusion??

% You need this thing instead:
find_pizza_hater(Person) :-
    likes(Person, _),         % first find a person that exists
    \+ likes(Person, pizza).  % then check if they don't like pizza

% This works:
% ?- find_pizza_hater(mary).
% true

~~~ hash table time ~~~

ok now lets start with the hashtable, i think this will be easiest if we break the code down into it's main parts.

the basics of our hash table

:- dynamic hash_bucket/3.  % stores (hash value, key, value)
:- dynamic table_size/1.   % keeps track of table size
:- dynamic item_count/1.   % counts our stuff

this tells prolog "hey, these things are gonna change while we run". think of it like creating variables that can actually change (which is weird in prolog). the /3 and /1 just mean how many parameters each one takes.

initialization (setting up our table)

init_hash_table(size) :-
    retractall(hash_bucket(_, _, _)),    % clear any old junk
    retractall(table_size(_)),           % out with the old size
    retractall(item_count(_)),           % reset our counter
    assertz(table_size(size)),           % set new size
    assertz(item_count(0)).              % start fresh at 0

this is like our constructor. retractall is basically "delete everything matching this pattern" and assertz is "add this new fact". the _ is prolog for "i don't care what this value is".

the hash function (where the magic happens)

hash_function(key, size, hashvalue) :-
    string_codes(key, codes),            % convert string to ascii numbers
    sum_codes(codes, sum),               % add them up
    a is 0.69420,                        % completely arbitrary constant...
    product is sum * a,                  % multiply
    fractional is product - floor(product), % get decimal part
    hashvalue is floor(size * fractional). % scale to table size

this is our hash function - nothing too fancy, just:
converts string to ascii numbers -> adds them up -> multiplies them by a completely random constant -> takes the decimal part and scales it to fit our table size

handling collisions

prolog actually makes this super easy. when multiple items hash to the same spot, they just... exist there. the backtracking system handles it automatically. when we look something up:

get(key, value) :-
    table_size(size),
    hash_function(key, size, hashvalue),
    hash_bucket(hashvalue, key, value).  % magic happens here
prolog will find the right one automatically by matching both the hash AND the key.

load factor and resizing

check_load_factor :-
    item_count(count),
    table_size(size),
    loadfactor is count / size,
    (loadfactor > 0.7 ->                 % if too full
        resize_table                     % make it bigger
    ;   true                            % else do nothing
    ).

when the table gets too full (>70%), we: double the size, grab all our current items and rehash everything into the bigger table

the recursive parts (because prolog)

rehash_all([]).                          % base case: empty list = done
rehash_all([key-value|rest]) :-          % for each item:
    table_size(size),
    hash_function(key, size, newhash),   % get new position
    assertz(hash_bucket(newhash, key, value)),
    rehash_all(rest).                    % do the rest

this is classic prolog recursion:

base case: empty list? doneski
otherwise: handle first item, then recurse on the rest

testing it out:

main :-
    init_hash_table(10),
    insert("key1", value1),
    insert("meaning_of_life", 42),
    % ... more insertions ...
    print_stats.

and that's our hash table!

here's the implementation in it's entirety. is it the most efficient implementation ever? probably not. but its cool how working with prolog can lead to a decent outcome.

% tell prolog these predicates will change during runtime
:- dynamic hash_bucket/3.  % stores triplets of (hash value, key, value)
:- dynamic table_size/1.   % keeps track of how big our table is
:- dynamic item_count/1.   % counts how many items we've stored

% sets up a fresh hash table with a given size
init_hash_table(size) :-
    retractall(hash_bucket(_, _, _)),    % clear out any old data
    retractall(table_size(_)),           % remove old size
    retractall(item_count(_)),           % reset item counter
    assertz(table_size(size)),           % set new table size
    assertz(item_count(0)).              % start with zero items

% our hash function - converts keys into table positions
hash_function(key, size, hashvalue) :-
    string_codes(key, codes),            % convert string to ascii numbers
    sum_codes(codes, sum),               % add up all the ascii values
    a is 0.69420,                        % pick a fun decimal number
    product is sum * a,                  % multiply sum by our number
    fractional is product - floor(product), % get just the decimal part
    hashvalue is floor(size * fractional). % scale to fit table size

% adds up a list of ascii codes recursively
sum_codes([], 0).                        % empty list sums to zero
sum_codes([code|rest], sum) :-           % for non-empty list:
    sum_codes(rest, restsum),            % sum up the rest
    sum is code + restsum.               % add current code to sum

% puts a new key-value pair into the hash table
insert(key, value) :-
    table_size(size),                    % get current table size
    hash_function(key, size, hashvalue), % calculate where to put it
    retractall(hash_bucket(hashvalue, key, _)), % remove old value if any
    assertz(hash_bucket(hashvalue, key, value)), % store new value
    update_count(1),                     % increment item counter
    check_load_factor.                   % see if table needs to grow

% finds the value associated with a key
get(key, value) :-
    table_size(size),                    % get table size
    hash_function(key, size, hashvalue), % calculate position
    hash_bucket(hashvalue, key, value).  % look up the value

% removes a key-value pair from the table
remove(key) :-
    table_size(size),                    % get table size
    hash_function(key, size, hashvalue), % find where it should be
    retract(hash_bucket(hashvalue, key, _)), % remove it
    update_count(-1).                    % decrease item count

% updates the count of items in the table
update_count(delta) :-
    retract(item_count(count)),          % get current count
    newcount is count + delta,           % adjust it
    assertz(item_count(newcount)).       % store new count

% checks if the table is getting too full
check_load_factor :-
    item_count(count),                   % get number of items
    table_size(size),                    % get table size
    loadfactor is count / size,          % calculate fullness
    (loadfactor > 0.7 ->                 % if more than 70% full
        resize_table                     % make table bigger
    ;   true                            % otherwise do nothing
    ).

% makes the table bigger when it gets too full
resize_table :-
    table_size(oldsize),                 % get current size
    newsize is oldsize * 2,              % double it
    findall(key-value,                   % collect all current items
            (hash_bucket(_, key, value)),
            pairs),
    retractall(hash_bucket(_, _, _)),    % clear the table
    retractall(table_size(_)),           % update size
    assertz(table_size(newsize)),
    rehash_all(pairs).                   % put items back in new spots

% puts all items back after resizing
rehash_all([]).                          % done if no items left
rehash_all([key-value|rest]) :-          % for each item:
    table_size(size),                    % get new table size
    hash_function(key, size, newhash),   % calculate new position
    assertz(hash_bucket(newhash, key, value)), % store it
    rehash_all(rest).                    % handle remaining items

% shows current table statistics
print_stats :-
    item_count(count),                   % get number of items
    table_size(size),                    % get table size
    loadfactor is count / size,          % calculate fullness
    format('table size: ~w~n', [size]),
    format('item count: ~w~n', [count]),
    format('load factor: ~2f~n', [loadfactor]).

% prints all items in the table
print_all :-
    hash_bucket(hash, key, value),       % find each item
    format('hash: ~w, key: ~w, value: ~w~n',
           [hash, key, value]),          % print it
    fail.                                % backtrack to find more
print_all.                               % succeed when done

% test the implementation
main :-
    init_hash_table(10),
    insert("key1", value1),
    insert("meaning_of_life", 42),
    insert("first_prime", 2),
    insert("random", 3498),
    remove("key1"),
    print_all,
    print_stats,
    remove("first_prime"),
    print_all,
    print_stats.

% tell prolog to run main when loaded
:- initialization(main).

cool prolog features that make this work:

• automatic backtracking: helps with collisions
• dynamic predicates: lets us modify the table
• pattern matching: makes lookups clean
• recursion: because prolog loves recursion
• fact-based storage: using prolog's database-like features

My goals for the rest of the year, when I like to set goals I prefer to set goals for systems not results, if I set a goal like "I want to get an A in x unit" this is a bad goal, since there are things about this goal I can't control. I could study super hard, do everything perfectly, all for my professor to crack the shits and fail the entire class with an impossible exam.

Instead I would set a goal like,

1. Study 2 hours a night
2. Go to office hours
3. Do all homework on time

etc. etc.

These goals set up a system that if I follow I am extremely likely to get an A in x unit.

Goal 1 Destroy opponent in grappling super fight

I've got another grappling super fight booked for the 28th of September. I don't rate my opponent at all so I really want to make a statement and walk through him. In order to achieve this here's my system

1. Cultivate a weekly training schedule with good training partners that works around my university and other commitments. (done)
2. Stick to the training plan for the next ~8 weeks
3. spend 30-60 minutes before every training session watching submeta in order to make sure I am improving technically.
4. Use Kenku to log all training sessions, use problems I log as study points and don't let the same issue happen twice. e.g didn't finish a daarce choke I'm looking up that defense before my next session and making sure that I know how to deal with it.
5. Pursue excellence in every part of the training session, warm up with excellence, drill with excellence, roll with focus and excellence. I'm not going to be able to spam mat time this camp so this is especially important.

Goal 2 Straight Hd's at Uni

My last semester of undergrad, make sure that I'm finishing with a bang, got some fire units this semester, make sure I'm making the most of them.

1. Do all homework on time (don't cheat)
2. Go to office hours and labs if I don't understand
3. Make friends with people in my units (This is so OP, I only started doing this last semester but the ROI is insane)

It's not a lot but to be honest I think doing this will be more than enough to get straight HD's ^_^

Goal 3 Figure out what I want to do with my life

idk man, this is a WIP, for now I think the best thing I can do is

1. Cultivate curiosity, keep learning cool shit and doing cool stuff for the sake of doing cool stuff.
2. Apply for as many grad roles as possible (get goated at interviewing)
3. Research and apply for postgraduate study
4. Take whatever option is the coolest

1. lot's of alpha in low status
2. go first
3. assume that everyone is a friend
4. indifference
5. there's no speed limit
6. risks are less risky than you think. take as many as you can.
7. spend 10-20% of your time reorienting
8. everything is power-law distributed
9. you can make yourself more lucky
10. lot's of roi in being a good person
11. you can learn anything
12. everything is figure-out-able
13. suffering is good
14. always select for excellence over specificity
15. drink water

Here's some of my favorite excerpts and quotes, I like collecting words so see this as a collection of words with the common theme being they come from the same place.

On the mentality of Mat Fraser (the Crossfit GOAT)

Mat consciously, every day, seeks out things he might be bad at. When he finds weaknesses, he doesn’t just work on them—he eviscerates them. One of the events he struggled with at the 2013 North East Regional was “Jackie,” a CrossFit benchmark workout of rowing, barbell thrusters, and pull-ups. He got dusted on the row—the other men were pulling 1:40 splits, and he was struggling to hold on to 1:50. That put him twenty seconds slower than the leaders, which was an enormous, unsurmountable gap. Relative to his competitors, he straight-up sucked at rowing. After Regionals, he went home, bought a rower, and for the next year, he rowed 4,000 to 5,000 meters of intervals—every day.

On mental reframes

Down on the beach, the complaining continues. Games documentarian Sevan Matossian asks one of the women, a three-year Games veteran, how she’s feeling after yesterday’s slugfest at the Ranch. Her response was included in the CrossFit-produced behind-the-scenes 2016 Games documentary: Waiting in the airport for so long at night, then having to get up really early, was really tiring. It’s already a lot harder than it was two years ago. The first day—everything from getting up early to three workouts in one day—that was a lot harder than what we did in 2014, when all we did on the first day was an ocean swim and then an overhead squat. I felt a lot better going into Thursday. And now we’re swimming on Thursday, so we don’t even get a rest day.

A few minutes later, Sevan finds Katrín, who is emerging from a warm-up dip in the surf. He asks her the same question. Here’s what she says I feel good! I was able to sleep a lot yesterday. I slept on the airport floor, I slept the whole plane ride, then I slept for five hours when I got into bed. I feel really good. I’m happy about that. Love that we get to go straight through with no rest day, love that. The more volume, the better. That’s great. So far it’s been amazing.

On Stoicism

At my gym, there’s an unbreakable threefold policy:

NEVER WHINE.NEVER COMPLAIN.NEVER MAKE EXCUSES.

If you talk about (or worse,complain about) things that are outside of your control, things that could diminish performance, you will see and experience more of those things.

As Ryan Holiday writes in The Obstacle Is the Way, “There is no good or bad without us, there is only perception. There is the event itself and the story we tell ourselves about what it means.” If your story is telling you you’re not good enough, not smart enough, too old, too young, or can’t do it, your subconscious will believe you.

On adversity

Elite athletes know something that most people don’t—adversity is the best thing that can happen to you. The competitors here at the Games know that humans only improve through adversity by embracing short-term pain. Ensuring there is no struggle, no challenge, and staying in your wheelhouse is a recipe for spinning your wheels without improving. It’s the days when you have to do things that scare you, when you have to take risks, when you have to push against challenge and difficulty—those are the days that make you stronger, faster, and better overall.

On autonomy

Racehorses are special. They’re not like just any other horse—they’re elite athletes, and they know it. They train with heart monitors, they do interval workouts, they have coaches and massage therapists, they eat a special diet, and they have recovery protocols. It sounds like I’m describing a human athlete, and I very well could be, because top racehorses and top human athletes are similar in just about every way but one. That one difference is crucial, and it gives racehorses a huge advantage over us: racehorses can’t think for themselves.

I get it; that doesn’t sound like an advantage. But think about it: racehorses are incapable of second-guessing their coaches, overanalyzing their performance, or logging junk miles. They’re unable to sandbag a workout if they’re not feeling up for training on a particular day. They don’t look at the other racehorses and compare themselves, or wonder if they’re with the right coach and training program. On race day, they don’t walk by the stalls of their competitors and think, Holy crap, look at the legs on him! How am I going to compete with that? Racehorses just perform. They can’t second-guess anything, and they have no biological choice but to have a laser focus on the task at hand. They’re able to do what we try to get our human athletes to do, as naturally as breathing. When they win, they don’t change anything about their routine, and they aren’t fundamentally changed. The next day is just another training day because winning (or losing) is part of the process, not the endpoint.

Racehorses aren’t biologically capable of understanding what their competitors are doing. They’re completely focused on themselves. That’s where I want my athletes. If an athlete’s goal is to beat their competitor, then, by definition, they’re not reaching their full potential—they’re simply clearing the bar of the next guy’s potential.

On deliberate practice

Deliberate practice can be characterized by the following four elements:

1. 1. It’s designed specifically to improve performance.
2. 1. It is repeated a lot.
3. 1. Feedback on results is continuously available.
4. 1. It’s highly demanding mentally, and not necessarily or particularly enjoyable, because it means you are focusing on improving areas in your performance that are not satisfactory.

The requirement for concentration is what sets deliberate practice apart from both mindless routine performance and playful engagement. The takeaway here is that while hard work is instrumental to success, it’s not enough. Obviously, the CrossFit Games does not hand out medals based on who spent the most time in the gym. Katrín didn’t win the Games last year because she logged more hours in the gym than all the other women. She won the Games because of the quality of those hours

I know you want me to let you in
on some big secret to success in the NBA. The secret is there is no secret. It’s just boring old habits.

On goals

Mat and Katrín have figured out the secret: that there is no secret. The process is about doing your job to the best of your ability, and Katrín and Mat wield it like a weapon. Do they want to win the CrossFit Games? Absolutely. But we don’t talk about it, and we certainly don’t make it a goal. Because what’s more important to success than a bold and courageous goal is developing a system—a process—to get there

On accepting what you cannot control

I listen to the buzz with growing content. This is the part of the process from which my athletes derive a considerable competitive advantage. As an elite athlete, there are only five things that you can truly control—your training, nutrition, sleep, recovery, and mindset. If it doesn’t fall into one of those categories, I tell my athletes, forget about it. Control the things you can control, and ignore everything else.

All of this is summed up by the tattoo on Mat’s left arm—the Serenity Prayer. You’ve heard it before: God grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference. It doesn’t matter whether you believe in God or not—this is exactly the mantra you want to lean in to. Let go of what you can’t change. Make room for the things you can.

Chapter Openings

The book opens every chapter with a quote, some of the quotes were absolute bangers, here they are

Opportunity is missed by most people because it is dressed in overalls and looks like work. —THOMAS EDISON

Sometimes when you’re in a dark place you think you’ve been buried, but
you’ve actually been planted. —UNKNOWN

When you have confidence, you can have a lot of fun. And when you have
fun, you can do amazing things. —JOENAMATH

One can have no smaller or greater mastery than mastery of oneself.
—LEONARDO DA VINCI

Only those who have the patience to do things perfectly will acquire the
skills to do difficult things easily. —FRIEDRICH SCHILLER

I was watching this video when the guest started talking about Cellular Automata. Earlier in the year I wasted quite a few hours on this site playing around with gliders, spaceships, ladders and other kinds of automata.

With more time on my hands I decided I wanted to play around and learn more about cellular automata. I have no idea why I find them so fascinating but I could watch them for hours. During the course of development for this project I lost a lot of time starting and re-running the simulation. There's something about such simple rules being able to create such vivid patterns that creates a psychedelic experience.

After researching practical applications for cellular automata I can upon this paper. Where someone used cellular automata to model the spread of COVID.

This didn't seem as sophisticated as other ideas that I was interested in like traffic flow (I'm coming for this later) so I decided to tackle it.

Here's an example run through

How it Works

The Simulation runs as a 75x75 grid in which each cell represents a person. There are four states represented by different colors as seen in the key on the right hand side of the simulation.

Each cell at any time can either be infected, recovered (but not immune), immune or normal (no state)

The simulation begins with the amount of "initial infected" being randomly distributed in the grid and then the days begin incrementing.

On each consecutive day infected cells can either recover with or without immunity, or infect their neighbors, as a neighbor to an infected cell your probability of being infected increased exponentially based on how many infected neighbors you have

Once a cell has been sick for the length of infection then they "recover" with a probability p of becoming immune for n days (all variables are adjustable by the user)

If you want to play around with the disease simulation yourself I'm hosting it here, plug in whatever values you want and go crazy.

If you're interested in the code and how everything works you can find that here. Any obvious bugs/huge errors feel free to make a PR or contact me.

Next steps

I enjoyed/am enjoying this project. But I don't know how far I can push it. I'm going to start reading "Designing Beauty: The Art of Cellular Automata" by Andrew Adamatzky and see what I learn/what inspiration I get. More Cellular Automata art/simulations are definitely on the cards.

This was far more tricky that I thought it was going to be and also ended up being the first time I ever used high school maths in real life. I really enjoyed the project and learning, so here's a post to share them with my friends and cement my understandings.

I'm going to walk through the steps that it took to get the foundation of these simulations going, it's not perfect but the meat and potatoes are there. By the end you'll be able to simulate some basic physics and have something that looks like this.

For this simulation I'm going to be using pygame, pygame is a nifty little library that makes it really easy to run simulations like these ones and get visual stuff up on the screen super quick whilst using all that python syntax that we all know and love.

Here's some boiler plate code, to initialize pygame, draw a screen and define some colors. This isn't really too relevant or interesting but I've included it for transparency.

import pygame
import math

# init pygame
pygame.init()

# draw a 600 x 600 window
screen = pygame.display.set_mode((600,600))

Now we have pygame, and a basic screen but we now want to start drawing stuff on the screen. Let's create a new Class to draw the large circle that will contain our ball.

class DrawCircle:
    def __init__(self):
        self.center = (300,300)
        self.radius = 255
        self.width = 3

    def draw(self):
        pygame.draw.circle(screen,WHITE, self.center,self.radius,self.width)

Look how easy that was! We've now got a screen with a nice white circle.

Now come's the tricky (but interesting!) part of this project. We need to make the ball bounce. Easy right???....

Lets start by creating our BouncingBall object and initializing some variables

class BouncingBall:
    def __init__(self):
        self.x = 300
        self.y = 300
        self.velocity = [1, 2]
        self.radius = 15
        # Elasticity is the amount of energy the ball loses when it hits something
        self.elasticity = 0.9
        # constant for gravity
        self.gravity = 0.5

Going through the variables,

The x and y coordinates will "spawn" our ball in the middle of the screen.

The ball's velocity is represented as a list [1,2] and controls the speed and direction that the ball moves in, it'll change over time to reflect the ball's differing speeds and directions. The first value (1) is the initial horizontal speed (changing x-velocity) of the ball and the second value (2) is the initial vertical speed (changing y-velocity) of the ball.

This means that the ball will start moving downwards and to the right. There's no specific reason for this apart from the fact that it give's it that nice arc as it bounces from left to right.

Elasticity is the amount of energy the ball is going to retain after it collides with the edge's of the outer-circle. An elasticity of 0.9 means that every time the ball collides it loses 10% of it's energy. Giving it a realistic bounce.

And then we have a constant for gravity. Gravity acts as a constant downwards acceleration on the ball and makes the simulation look far more "real".

Simple enough!

Now for the real fun part! Let's get this bad boy moving!

    def move(self):
        # Apply gravity
        self.velocity[1] += self.gravity
        self.x += self.velocity[0]
        self.y += self.velocity[1]

Simple enough, we apply gravity to the y value of the velocity (thus pulling it down a bit) and then move the x and y values of the ball depending on the ball's current velocity in each of the directions.

But currently we don't check if the ball has hit the edge of the circle. So it's just going to move in one direction forever, let's change that and add some collision detection!

To figure out if the ball has collided with the edge of the circle we can imagine the ball's coordinate and the center of the big circle forming two points of a perfect right-angled triangle. We can then use Pythagoras theorem to calculate how far the ball is from the center and use this information to check if it's at the edge.

In code

if self.distance_to_center() + self.radius > 255:
    # The ball collided with the edge of the circle

def distance_to_center(self):
    # Pythagoras
    return math.sqrt((self.x - 300) ** 2 + (self.y - 300) ** 2)

Now that we know we have hit an edge we need to get (and thus calculate) that sweet, but so ever so elusive "bounce".

In order to do this we are going to have to go back to high school and refresh our knowledge of vectors.

A vector is a quantity that has both magnitude (length) and direction. In our case the ball's velocity is a vector because it describes how fast the ball is moving and the direction that it is moving in.

A normal vector is just a vector that's perpendicular (90 degrees) to a surface. In this case the normal vector is going to represent the direction from the point of collision towards the center of the circle.

But how do we calculate the normal vector?

We first have to find the vector pointing from the ball towards the center, we can do this quickly by subtracting 300 (recall that the center of the large circle is 300,300) from both the x and y coordinates of the ball. Which will get the same point on the opposite side of the circle. As seen in the image below.

normal = [self.x - 300, self.y - 300]

Then once we have the vector pointing directly from the ball to the center we need to calculate the magnitude (length) of the current vector. This is the length from the ball to the center of the circle. Again we can use good old Pythagoras to do this.

normal_length = math.sqrt(normal[0] ** 2 + normal[1] ** 2)

But you may have realised a problem, this is gonna get really big really fast, and we don't actually care about the length, we only care about the direction so we can normalize this value. To make it more normal and avoid things like buffer overflow and let's us have more accurate, less exaggerated velocities.

We can do this by dividing each component of the vector by its magnitude again this will keep the overall direction of the vector the same, whilst managing the overall length.

normal = [normal[0] / normal_length, normal[1] / normal_length]

In fancy terms this is now called a unit vector because it has a length of 1.

Ok cool, now we have the normal vector, that wasn't so hard but how is this going to help us bounce? Intuitively we can't just make the ball exactly from the point and back, this isn't how bouncing works. When I throw a ball at an edge it doesn't just move straight back towards me, but how it bounces should be impacted by the angle and speed that the ball collided with the target.

To do this we first we need to calculate the dot product between the velocity and normal vectors, the dot product is a way to multiply two vectors that results in a single number. It combines the corresponding components of the vectors and then sums the products to do so.

In this scenario the dot product between the velocity and normal vector's tells us how much of the velocity is directed towards the collision point. A positive dot product means that the ball is moving towards the collision point, and a negative means it is moving away.

Here's an example that skip's normalization for simplicity sake.

In the code this looks like so

dot_product = self.velocity[0] * normal[0] + self.velocity[1] * normal[1]

The dot product is going to determine how much of the ball's velocity is directed towards the center of the circle (the normal direction).

We now also need to reflect the new Velocity vector, to give the new direction that the ball is going to move in.

We can use a nice math trick here to reflect the velocity vector.

If we multiply the normal vector by twice the dot product the code essentially flips the component of the velocity vector that's parallel to the surface (represented by the normal vector). This effectively changes the direction of the ball based on the angle of impact.

In the code

self.velocity[0] -= 2 * dot_product * normal[0]
self.velocity[1] -= 2 * dot_product * normal[1]

We can't forget about adding elasticity, if we forget this the ball will just bounce forever, this isn't really realistic so we will multiply the ball's velocity by the elasticity constant to take away 10% of the balls speed every collision.

self.velocity[0] *= self.elasticity
self.velocity[1] *= self.elasticity

Now we have a bit of a problem. As the code currently stands the ball will get stuck inside the boundary and break everything. We can add a small amount of overlap to the ball to prevent it from getting stuck in the curvature of the boundary.

overlap = self.distance_to_center() + self.radius - 255
self.x -= normal[0] * overlap
self.y -= normal[1] * overlap

And that's all the maths and physics done. Easy peasy! Now to get things cooking let's quickly add a draw method to draw the bouncing ball to the screen.

def draw(self):
    pygame.draw.circle(screen, RED, (int(self.x), int(self.y)), self.radius)

Now create instances of the outer circle and bouncing ball and add a game loop.

circle = DrawCircle()
ball = BouncingBall()

# Game loop
while 1==1:
    # Move the ball
    ball.move()

    # Clear the screen
    screen.fill(BLACK)

    # Draw the circle and the ball
    circle.draw()
    ball.draw()

    # Update the display
    pygame.display.flip()

    # Cap the frame rate
    pygame.time.Clock().tick(60)

Done!

Here's the full code if you want to try it on your machine or play around with the values. Just pip install pygame if you haven't already and it'll work out the box :))).

import pygame
import math


# init pygame

pygame.init()

# draw a 600 x 600 window
screen = pygame.display.set_mode((600,600))
pygame.display.set_caption("BOUNCY BOUNCY!")

BLACK = (0,0,0)
WHITE = (255,255,255)
RED = (255,0,0)


class DrawCircle:
    def __init__(self):
        self.center = (300,300)
        self.radius = 255
        self.width = 3

    def draw(self):
        pygame.draw.circle(screen,WHITE, self.center,self.radius,self.width)

class BouncingBall:
    def __init__(self):
        self.x = 300
        self.y = 300
        self.velocity = [1, 2]
        self.radius = 15
        # Elasticity is the amount of energy the ball loses when it hits something
        self.elasticity = 0.9
        # constant for gravity
        self.gravity = 0.5

    def move(self):
        # Apply gravity
        self.velocity[1] += self.gravity
        self.x += self.velocity[0]
        self.y += self.velocity[1]

        # Check for collision with the boundary of the larger circle
        if self.distance_to_center() + self.radius > 255:
            # Calculate the normal vector at the point of collision
            normal = [self.x - 300, self.y - 300]
            normal_length = math.sqrt(normal[0] ** 2 + normal[1] ** 2)
            normal = [normal[0] / normal_length, normal[1] / normal_length]

            # Reflect the ball's velocity around the normal vector
            dot_product = self.velocity[0] * normal[0] + self.velocity[1] * normal[1]
            self.velocity[0] -= 2 * dot_product * normal[0]
            self.velocity[1] -= 2 * dot_product * normal[1]

            # Apply elasticity
            self.velocity[0] *= self.elasticity
            self.velocity[1] *= self.elasticity

            # Move the ball slightly outside the circle to prevent sticking
            overlap = self.distance_to_center() + self.radius - 255
            self.x -= normal[0] * overlap
            self.y -= normal[1] * overlap

    def distance_to_center(self):
        return math.sqrt((self.x - 300) ** 2 + (self.y - 300) ** 2)

    def draw(self):
        pygame.draw.circle(screen, RED, (int(self.x), int(self.y)), self.radius)

# Create instances
circle = DrawCircle()
ball = BouncingBall()

# Game loop
while 1==1:
    # Move the ball
    ball.move()

    # Clear the screen
    screen.fill(BLACK)

    # Draw the circle and the ball
    circle.draw()
    ball.draw()

    # Update the display
    pygame.display.flip()

    # Cap the frame rate
    pygame.time.Clock().tick(60)

Design an algorithm for finding the k-th smallest element in an unsorted array of length n that is faster than O(n log n) amortized. Analyse the complexity of your algorithm assuming k as a constant. (5 marks)

This really stumped me, I couldn't figure out how do this in less than O(n * log(n)) time. But now after researching, I know. And I think the algorithm is pretty cool. So for your enjoyment and my retention here it is.

We can use Quick Select to find the K-th smallest element in an unsorted array in average linear O(n) time.

Here's the steps to the algo

You pick a random element to partition. For simplicity sake I will just always select the last element in the array but in order to achieve the average complexity of o(n) you're going to be better off choosing random elements.

The goal of the partition is to adjust the array so every element greater than the element you selected is to the left of the array and every element greater than or equal to the element is to the right.

The way this works is by using two pointers initially both set to the first index of the array and increment the one of the pointers, (the j one in the graph below) at every step. Every time we increment J we are looking if the J element is greater than the partition. If it is then we swap j with wherever i is and increment i as well. We do this until we are at the partition. When we are at the partition element we swap it with wherever i currently is. Here's a visual example I drew up. (note the Exalidraw skillz).

Obviously it's pretty unlikely that we find the correct index at the first element. But what we do know after the first element is that all elements to the left of wherever the partition ended up are less than the element and all elements greater than the partition are to the right. So we can just call the function recursively on either the right or left side of the array and do so repeatedly until the index where the element ended up is correct to the k-th smallest element (with 0-based indexing this is just going to be k-1).

Time complexity

The worst case time complexity of the algorithm is going to occur when we repeatedly pick the largest or smallest element unsorted elements as the pivot, leading to one partition having n-1 elements and the other partition having 0 elements. As then we are going to have to sort the entire array to find our answer.

T(n) = T(n-1) + cn

= T(n-1) + T(n-2) + cn + c(n-1)

= T(n−2)=T(n−3)+c(n−2)
we can observe a general pattern in the expansions
= T(n)=T(n−k)+c(n−k+1)+c(n−k+2)+…+cn
which can be summarised as
= T(n)=T(1)+c⋅* ((n(n+1)) / 2 )
= O(n²)

If you haven't seen this notation before T(n) is the time to solve the problem for an array of size n, and T(n-1) is the time to solve the problem for an array of size T(n-1), which is now the case since this is the side of the partition we are going to look at next. Here cn represents the linear time (c for constant) to partition the array of size n. Expanding and summarising the recurrence relation shows that the worst case time complexity is going to be quadratic O(n²). This is obviously unlikely though as we would have to continuously choose the worst options.

The best case occurs when we partition the list into two roughly equal halves and continue with half the array.

T(n) = T(n/2) + cn

= T(n/4) + c(n/2) + cn

= n (1 + 1/2 + 1/4 + ...)

= 2n

= O(n)

The average case (and thus the amortized complexity) of quick select can be shown to be O(n) (linear time) as we will partition log(n) times on average.

T(n) = T(n/2) + O(n)

Solving this recurrence relation:

T(n) = T(n/2) + cn

= T(n/4) + c(n/2) + cn

= T(n/8) + c(n/4) + c(n/2) + cn

= ...

= T(1) + c(n + n/2 + n/4 + ...)

The sum inside the parentheses is a geometric series:

n + n/2 + n/4 + ... = 2n

which will sum up to:

T(n) = O(n)

Showing that on average quick select takes linear time, super cool.

Here's the python implementation ^_^

# The code for the partition

def partition(arr, l, r):
  # for simplicity we will set the partition to the last element in the array
  pivot = arr[r]
  # set i to the leftmost element of the current partition
  i=l
  # increment j one step at a time
  for j in range(l,r):
    # if the current element is less than the pivot we need to swap it with i and increment i
    if arr[j] <= pivot:
      arr[i], arr[j] = arr[j], arr[i]
      i+=1
  # once we are at the partition element we swap it with wherever i currently is
  arr[i], arr[r] = arr[r], arr[i]
  # return the index of the parition element (that is now in its correct spot)
  return i


def quick_select(arr, l, r, k):
  # partition relevant part of the array
  pivot = partition(arr, l, r)
  # if the pivot is in the correct spot return the element
  if pivot == (k-1):
    return arr[pivot]
  
  # if its greater than then we need to look at the left hand side of k
  if pivot > (k-1):
    return quick_select(arr, l, pivot-1,k)
  # else we need to check the right hand side
  else:
    return quick_select(arr,pivot+1,r,k)

Very Useful video (whose code I stole and explains this far better than I do)

The catch here is that the opportunities come when it's easiest to keep working towards them, or in other words. You get rewarded long after you've done the hard work and sacrifice not during or directly after. The hardest time to train a combat sport consistently is either when you have just started (in which you're going to get no opportunities, recognition or anything of the like) or when you haven't seen the fruits of your labor for a long time. Any combat sports athlete whose trained at a high level for a long enough period of time will have experienced this. You're training your ass off, you're getting better than ever, but there's just nowhere to show off your skills. This can be disheartening and that's why it's so important to remember that the opportunities and fruits of your labor are going to be far far far upstream of where you are now.

The longer you can do the work without getting anything in return the greater the upside will be in your return

On the other hand although opportunities increase exponentially skill increases pretty linearly. (I know there are peaks and troughs but let's average it out ok), the best way to capitalize on opportunities is by having a high degree of skill, preferable a much higher degree of skill relative to the amount of opportunities you currently get.

If you're familiar with the elo rating system you can think of skill as your "true skill" and the opportunities you get (super fights, seminars, etc.) as the amount of elo you have. If your true skill is far higher than your elo, then when someone gives you an opportunity (a super fight) or you create one yourself (fly to America to compete in worlds) you're going to have a much higher chance of capitalizing on it. Since your skill is much higher than your perceived level.

This should be the main focus for athletes, just focus on getting better. Getting better is never going to hurt your career or the amount of opportunities you get, in fact it's going to significantly increase what you can do and make of the opportunities you get.

tldr:

1. Getting good is the best way to get more opportunities

2. Opportunities will present themselves far downstream of the hard-work. It's important to remember this and consistently get better.

3. Working hard while getting nothing in return will increase the upside when you eventually do get an opportunity.

Disjoint set's are set's in which the union of said set's results in the empty set. Or in more normal speak, if you take all the common element's from both sets and try to create a new set then this set will be empty (the set's have no common elements).

We can use disjoint set's to represent things like social media networks or a network of trains. The train example is a good one to use to understand the idea. If each interconnected group of train stations is a set then these set's are going to be disjoint. It's easy to see that if we can somehow get to train station x, then we can also get to every train station from train station x. So if we can get to train station x we should add train station x (and all the stations connected to train station x) to the station that can get there (which we represent as a disjoint set). After we do this for every train station, each set is going to represent a network of interconnected trains. From this we can easily tell if you can or cannot get from one train station to another by seeing if two stations are in the same set. If they are, we can get from one to the other, if they aren't, no bueno.

But now the switched on observer (not me), might exclaim. But Josh! This is going to take quadratic N^2 time! First you're going to take O(N) time looking at each element and then for each element you're going to have to look at every element to see what it's connected to! This is just a naive solution with extra steps!

If this is you stop reading now, you're only going to get dumber reading joshshipton.com, this is way below your pay grade.

But that's a good point! One potential optimisation is to represent the set as a tree, and then look up the tree towards the root to see if the two elements have the same root, this is a good optimisation and would lead the find operation to take O(h) time where h is the time of the tree. But we can do even better.

This is where the real magic of the Union-Find part of the solution comes in, when we union our set's together we can do something magical called path compression which represents the nodes/elements in the set as a flat graph in which we arbitrarily choose a representative to act as the "root" of the graph. Or in other words, pick an element. Make every element in the set point to that element.

This means that if we want to check if two elements are in the same set instead of having to go all the way back up to the root, we only have to go up one element and check that two sets have the same representative. This is really fast, we are talking inverse Ackerman O(α(n) time. And means that the whole solution takes O(N+M * α(n)) time, where n is the amount of elements, and m is the amount of operations. This is for all practical applications constant time. (borat voice) Very nice!.

Post Script

I found these links really helpful when trying to understand Union-Find.

great video

handy article(W3 schools goated)

Here's some example code from one of my university labs

class UnionFind:
    def __init__(self):
        # Initialize the parent and rank sets
        self.parent = {}
        self.rank = {}

    def find(self, city):
        # Recursively find the root of the city with path compression
        # if the self.parent[city] is not the city itself then we need to find the root of the city
        # and set the parent of the city to the root of the city
        # this is done to reduce the height of the tree and make the find operation faster taking inverse Ackermann function time
        if self.parent[city] != city:
            self.parent[city] = self.find(self.parent[city])
        return self.parent[city]

    def union(self, city1, city2):
        # Find the roots of the two cities
        root1 = self.find(city1)
        root2 = self.find(city2)

        # If they are in different sets (have different roots), then you merge them together
        # we can merge the two sets by attaching the root of the smaller tree to the root of the larger tree
        # this works because the root of the tree is the representative of the set
        # and the rank of the tree is the height of the tree
        if root1 != root2:
            # Attach the smaller tree under the root of the larger tree
            if self.rank[root1] > self.rank[root2]:
                # If the rank of the first city is greater than the rank of the second city, then we set the parent of the second city to the first city
                self.parent[root2] = root1
            elif self.rank[root1] < self.rank[root2]:
                # If the rank of the first city is less than the rank of the second city, then we set the parent of the first city to the second city
                self.parent[root1] = root2
            else:
                # If ranks are the same, arbitrarily choose one and increment its rank
                self.parent[root2] = root1
                self.rank[root1] += 1

    def add(self, city):
        # Add a city as a new set if it's not already present
        if city not in self.parent:
            # Set the parent of the city to itself and the rank of the city to 0
            self.parent[city] = city
            self.rank[city] = 0

def trains_planes(trains, planes):
    """
    Find what flights can be replaced with a rail journey.

    Initially, there are no rail connections between cities. As rail connections
    become available, we are interested in knowing what flights can be replaced
    by a rail journey, no matter how indirect the route. All rail connections
    are bidirectional.

    Target Complexity: O(N lg N) in the size of the input (trains + planes).

    Args:
        trains: A list of `(date, lcity, rcity)` tuples specifying that a rail
            connection between `lcity` and `rcity` became available on `date`.
        planes: A list of `(code, date, depart, arrive)` tuples specifying that
            there is a flight scheduled from `depart` to `arrive` on `date` with
            flight number `code`.

    Returns:
        A list of flights that could be replaced by a train journey.
    """
    # Initialize the UnionFind data structure
    uf = UnionFind()

    # Sort trains and planes by date
    trains.sort(key=lambda x: x[0])
    planes.sort(key=lambda x: x[1])

    # Initialize the train index and the result list
    train_index = 0
    result = []

    # Iterate through all the planes
    for code, date, depart, arrive in planes:
        # Process all trains that are available by this date
        while train_index < len(trains) and trains[train_index][0] <= date:
            # Add the cities to the UnionFind data structure
            _, lcity, rcity = trains[train_index]
            uf.add(lcity)
            uf.add(rcity)
            # Merge the cities into the same set
            uf.union(lcity, rcity)
            # Increment the train index
            train_index += 1

        # Check if this flight can be replaced
        # If the departure and arrival cities are in the same set, then the flight can be replaced
        uf.add(depart)
        uf.add(arrive)
        # Use the find operation to check if the departure and arrival cities are in the same set
        if uf.find(depart) == uf.find(arrive):
            # If they are in the same set, then the flight can be replaced
            # Add the flight to the result list
            result.append((code, date, depart, arrive))

    # Return the result list
    return result

The beauty of the solution lies in its simplicity. It will never search through more steps than the optimal amount of steps since it will try every single possible solution up to n (where n is the amount of steps in the best case solution). I love the fact that even though the algorithm doesn't know the solution by trying every possible solution one step in a time it will always stumble upon the best solution. It will never waste time computing steps past the optimal solution (if an optimal solution exists).

Take the Min knight moves problem as an example. I'll attach some sample code and walk through the solution.

# Import the deque data structure from the python standard library
from collections import deque

# for simplicty sake lets assume an infite sized board, lets start at 0,0 and try to get to our destination
def find_min_moves(dest_x,dest_y):

# define all the possible moves a knight can make
    possible_moves = [(2,1), (2,-1), (1,2), (1, -2), (-1, 2), (-1, -2), (-2, 1), (-2,-1)]

    # initialize a set to keep track of squares visited
    visited = set()
    # initalize the queue with the starting point the third value is the amount of steps we are currently at  
    q = deque([(0,0,0)])

    # while there are elements in the queue we have positions to look at 
    while q:
    # get the x and y coordinates and the current amount of steps from the left of the queue
        x,y,steps = q.popleft()

    # if we have already seen x and y we don't need to look at it again
        if (x,y) in visited:
            continue
    # if we are at our destination we can return
        if x == dest_x and y == dest_y:
            return steps
    # add the current destination to visited
        visited.add((x,y))

    # try every possible move from where we currently are and append it to the queue to be looked at later
        for move_x, move_y in possible_moves:
            dx = move_x + x
            dy = move_y + y
            q.append((dx,dy,steps+1))
  
    # if we haven't found a solution we can return -1.
    # for an infinite sized board however there will always be a solution if the coordinates are valid
    return -1

# feel free to test the function
print(find_min_moves(5,3))

I also tried to build a way to visualize this, but my javascript is a bit rusty and it didn't work out too well. But here it is anyway.

About the interview

The interview was for a summer internship (software dev) at a pretty large trading firm. This interview was the first interview after the online assessments. It was described as purely behavioural but ended up being half-behavioral half-technical (amazing bait).

What went wrong

The interview started off alright. The behavioral section was pretty standard. "why do you want to work here", "tell me about x" , "tell me about a time when..." etc. I don't think it went amazing but I also don't think it went terribly. I glossed over some things, that in retrospect I should have said but had fairly-decent answers for everything. But then we got to the technical stage of the interview, and this is where I fumbled hard.

After finishing off her behavioral questions the interviewer asked me for my favorite programming language (I said python please don't judge me) and told me we would do a quick exercise.

The task was seemed pretty simple. The interviewer shared her screen told me to summarize what the code was doing. For context we are probably talking about 30 or so lines consisting of two classes with around 6 functions in total and a constructor. My brain stopped working immediately.

Seeing a bunch of unfamiliar syntax like @abc.abstractproperty decorators, and words to do with network protocols that I only had a vague understanding of immediately put me in a "I don't know what this is mindset". I freaked out over not understanding every aspect of the code when in retrospect I probably knew enough to give a decent answer.

What I should have done and what I think would have been perfectly fine would be to answer the question as best as I could whilst telling my interviewer that I didn't understand some parts of the syntax and code but make an educated guess as to what it was probably doing. This would have been far better than what I actually did (feel free to laugh or tease me), which was ummmm, ahhh and say "sorry I don't know".

Eventually after bombing the first 3 questions I found my stride, still answering in an unsure tone but giving more coherent answers that were probably correct. But by then it was too late, the interviewer gave curt replies and it was clear that the rest of the interview was nothing but a formality.

What I learnt

• If you don't know you don't know. But try to answer anyways. Asking questions and giving an educated guess is far better than giving up

• Be confident the entire time, don't let things phase you or lose your stride

• Your entire "story" for behavioral interviews should be written out to make sure that you communicate yourself, your achievements and your background to the interviewer in the most clear, efficient way possible.

What I'm doing for next time

• In the past I've practiced my replies for common behavioural questions (list here) but never for questions like "tell me about your background" , "tell me about x club at university" etc. assuming that if asked these questions I would just be able to answer them. But writing out model answers really helps improve the clarity of your response. So I'm going to be more thorough with this next time.

• More mock-interviews with friends that isn't just DSA. Big one, been going hard on the DSA for a while, time to branch out a bit more.

• Practice communicating technical ideas, I'm giving some lectures on algorithms at my university in the next few weeks. I'm going to use this as an opportunity to get more competent with formal technical discussion. Shooting the shit about my favorite web-framework with the lads = easy peasy, doing it formally != easy peasy. I talk rubbish and give strong opinions about things I saw once on Reddit with my friends all the time but communicating formally is something I do far less often. To improve this I'm going to look for more opportunities to be forced to talk formally about technology.

Ad Santel or his real name Adolph Ernst was one of the greatest practitioners of catch wrestling. The coolest aspects of his life can be summarised as

• World Light Heavyweight Catch Wrestling Champion
• Wants to challenge himself more
• Decides to challenge the best judoka in the world in their own rule set
• Wins
• Declares himself Judo World Champion
• Jigiro Kano gets irritated and sends more of his best practitioners
• Santel keeps winning
• Kano gives up and stops sending people
• So Santel decides to travel to Japan to fight more judoka
• He wins one match and draws another. But the Japanese people are so fascinated that is sparked a new age of catch-wrestling in Japan.

Highly recommend his Wikipedia page as a starting point if you want to read up on him. A great example of a well rounded grappler with crazy confidence. Somehow I had never heard about this guy but now he's my new hero

The chad himself

I am convinced that there are numerous ways that software can improve human performance in combat sports, since my focus is grappling sports such as wrestling, submission grappling and Judo I’ll focus my scope on these rule-sets.

All software can be condensed as processing and presenting information, what information can we process and present to help athletes improve faster and train smarter? Here are some examples of projects I know of and projects that I would like to see.

Current projects that i know of

Learning management platforms

There are countless examples of these, I feel at the moment submeta is leagues above everyone else with its roadmaps and super crisp front-end.

Move databases

Outlier Database

Projects like this are tedious to create but I could see them providing a ton of value. Some things to improve would be accessibility and consistent UI and labeling.

Graphical

code
Try it here

Cool graphical tool to experiment with different move combinations. Not sure how useful this is but its super cool to play around with

Digital (smart journals)

Kenku was built by me. It offers a digital training journal. Digital journals have the benefit of being far more indexable than traditional paper journals. Is still a work in progress but is available for anyone to try. If you want to learn more read this

Elo ranking systems

People have scraped BJJ heroes and other sites that store match results and then used some math to create an elo rating to objectively rank the top BJJ practitioners. I think that projects like this have a lot of potential.

Good use cases I can think of are in sports like Judo were qualifying points are very important. Projects like this could be used to calculate the average elo at certain competitions and then optimize for the competition that has the highest amount of qualifying points with the lowest elo competitors.

code

Projects that I would love to see

AI referees for Judo

Simple, train a model on a ton of Judo throws. Get the model to a point where it can classify a throw as no-score, wazari or Ippon. There is way too much subjectivity at high-level judo competition for an aspect of the rule set which I believe has some of the most objective criteria. (1-shoulder = wazari, 2 shoulders = ippon, no shoulders = no score )

Thinking about what features to implement/add

I think that this is the hardest thing to actually sit and do, it seems easy but you need to make sure that what you've decided on is worth invested time into and also that it's something that is actually needed. Big decision so I don't try and do it unless I have the energy to do so.

Thinking about how to implement a feature

Quite hard depending on the feature but I really feel as though this is the brunt of the work and bears the most cognitive load. Involves doing research, reading other peoples code that achieves something similar and playing around with different posibilities. During this step its important to map out every thing that needs to be done to achomplish the task sequentially and in detail. You dont want to just leave this information in your brain you want to put it somewhere.

Actually implementing the feature

If you;ve done the prior step well this is actually really easy. If its not easy you need to go back and spend more time in the previous step. This might be a hot take but I believe that if the implementation isnt easy you havent spent enough time thinking about the implemenation and its a sign that things are going to go downhill very fast very soon.

Fixing little backend bugs

Through me and my users using my projects I find little bugs from time to time, nothing breaking but things that would just be nice to fix. These are usually quite easy to fix so as long as theyre not breaking the application I save them for when I'm tired as nice easy wins to keep momentum.

Fixing front-end or UI bugs

Same as the previous point but even easier. Nowadays most front-end bugs can be fixed by describing what you want in good detail and asking a certain tech-overlord very nicely. Of course review the code nicely and iterate on it either by yourself or with more prompts but this is quite easy. If they're not complying just figure it out youtself or steal some components. It's more of a "take some time and patience thing" than a "think logically and use your brain intensly thing" so I do this when I'm my most tired.

Don't build confidence without evidence

Confidence without evidence is an illusion, you're tricking yourself into being confident even though you don't have the backing to support your beliefs. This is pretty much lying to yourself. Confidence without evidence is an illusion, you should do things so you become confident, You shouldn't wait until you're confident to do things. Fake it till you make it should become "walk it before you talk it" prove it to yourself so you don't have to prove it to others, let your path do your talking for you.

Solve for proof

The message is 10% of how people perceive what you say. Context is everything else. Example of Elon being able to tweet whatever he wants and it going crazy. The context of Elon and everything he has achieved allows him to do this. Solve for evidence over everything else. If a billionaire is giving business advice someone can't say "you don't know anything about business" because objectively they do. Even if what they're saying is wrong, people or someone else is saying the same thing without the credentials but communicating it better will listen to them just because of what they've done.

Measuring

Don't measure by results, measure by effort. If someone is doing better than you, compare your input to their input (what they're doing to get that result) and not their output. The output is irrelevant because it's the input that really matters. If you're putting in a greater amount of input than someone else over a long enough time period the output's will start to reflect the relative inputs. The greater the difference between the inputs the faster the outputs will change.

Lagging metrics vs lagging metrics

lagging metrics = what happens (outputs)
leading metrics = the inputs that create the outputs

Track leading metrics not lagging metrics. Don't track your weight, track your calories. etc. etc.

the Delta between what you did and what you could have done

Focus on the delta between how hard you try and how hard you can possibly try. The gap between these two values is all that matters because it's all that you can control. You should redefine your concept of "winning" to how small the difference between these two deltas is. Because at the end of the day that's all you can control. It's also more immediate, you see results straight away, this makes it far more motivating to stick with.

By default if you don't give up, you win

The best games are ones where there isn't an end goal.The goal is just to keep playing business, marriage, being healthy are all like this. So by definition if you stay in the game you're winning. He uses an example of Kobe being asked " do you think you're someone who is afraid of winning or someone who loves losing" and him replying "I just love playing to the best of my ability". There aren't two frames “winning" or "losing" this is a false dichotomy. As long as you're playing you're winning by default. If you change your definition of winning to be reliant on your character, and judge your days based on this, as long as you contributed to the character of the person that you wish to become, then you won the day.

Bunch of great one liners in this section

if you have the menu item of things you can do in life, just remove quitting as one of them and then try your next thing.
The rocky cut scene in the move lasts 2 minutes in real life it lasts a lot longer
this is where most people stop, and this is why they don't win
if you play to win you'll be out first. play to outlast and you'll win.

Other people's opinions

The best thing you can do for your own life is not to listen to other people's opinions about your life. Most people don't want the best version of you. They want the version of you who best suits them. More people root for you when you have succeeded than people who rooted for you along the way.

Whenever someone gives you an opinion of what you should do with your life it's really what they want to do with their life. People make statements to release their discomfort e.g "you should train less" "your standards are too high” etc etc. and that's their problem not yours so dont worry about it.

I am statements

People like saying they are things and then love giving a "because" reason...

The “because” adds nothing, and most of the time you don't even know why you are that way and you're just guessing. All you know is that you do a certain type of behavior. By giving these “because” statements power you put things in the past. if you change the mentality to "I do x". then you just change your day to day behavior and give the control to your present self.

Epic stories razor

When choosing between two or more options choose whatever will create the cooler story. Reframe "these are all the reasons that i can't succeed" to. "These are all the reasons why when I succeed it will be awesome.

Heroes vs villains

heroes and villains in stories always have the same backstory - pain. The difference is what they choose to do about it. The villain says "the world hurt me, i'll hurt it back". The hero says "the world hurt me, I'm not gonna let it hurt anyone else" Heroes use pain. Villains are used by pain.

Everyone inevitably feels pain. It's a constant of life, you just have to choose how you deal with it.

Document your life

Document your life when it sucks, not when it's great. Because these are the moments that you can use in the future to prove who you really are. Quote from the matrix

I stand here truthfully unafraid. Not because of the path that lies before me but because the path that lies behind me - Morpheus

The struggle or hardship that you might be facing right now is the path that your successful future self looks back on to be confident in whatever path lies in front of them.

Short summary of a framework from Chris Willaims that's been super useful in my day to day life.

I all too often find myself consuming content that I don't actually want to be consuming or that I regret watching afterwards. Chris explains that the reason this happens is because the heuristic most people use when deciding what content to consume is "is this captivating or not". Not only does this optimize for the wrong thing (short term pleasure > long term benefit) but also anything you're watching is always going to be captivating because if it wasn't then you wouldn't be watching it.

The framework Chris suggests to use to combat the problem of content captivity is to either before consuming or whilst consuming content project yourself into the future to after you've consumed the content. He calls this "Post Content Clarity" as only after you've consumed a piece of content and it's stopped grabbing your attention can you really assess its impact. I've found this super useful in order to stop my attention being stolen by whoever is the most bold, eccentric and aggressive and instead make sure it's being given to whoever is the most interesting and beneficial.

Example

I start watching something, I realize that after watching this I'm probably going to feel worse about the future of our species. I turn it off. I see another video, I realize that after watching it I'll be more informed about a topic I care about. I press on the video.

I'll end this little summary with one of my favorite quotes from Chris.

“Your content diet should be spirulina for the soul, not fast food for your amygdala.”

What is spaced repetition?

If you've ever used anki. That's spaced repetition. If you've never used anki, think of spaced repetition as the most effective way to remember things. Flashcards on algorithmically enhanced steroids that make sure you review things at the optimal intervals to deliver enhanced learning.

How it works

If you're trying to learn something by committing it to memory, it's been proven that the best time to review something is just before you forget it; if you review something straight after learning, that's too easy, but wait too long, and you can't review it at all.

Our brain forgets things on a curve, appropriately called the forgetting curve. In our use-case we are recommending grappling techniques to the user. We can use this forgetting curve to figure out when to recommend users review techniques at the optimal time. To do this we need to model the forgetting curve. This can be broken down into two steps.

• One. Model how memorable that a certain technique is to a user(the more memorable, the longer they will remember it without review).

• Two. Figure out how good a certain user is at remembering things. Some people are going to have inherently worse or better memories than others; for them, I will have to adjust the rate of decay in the algorithm accordingly.

Ultimately, a good spaced repetition algorithm would quickly determine how memorable something is to a user and how good the user's memory is based on how well they have recalled techniques in past reviews. It would then use this information to recommend techniques at the optimal time.

Why is this useful for Sports?

Good question. Unlike sports where the win condition is based purely on physical prowess (think swimming, running etc), grappling is a sport with a large cognitive component. Being analytical and cerebral is an important asset and to cultivate these attributes athletes study for hours outside of training, they also practise and play around with moves until they understand every small detail. Just like studying for academic subjects, consistency plays a huge role. It doesn’t make much sense to study one thing for 10 hours straight and never touch it again. But knowing when to work on what is difficult. This feature of kenku.org hopes to direct users when they should study and review certain techniques to help them learn faster and better.

Problems with relation to Kenku.org

• I'm working with skills that aren’t strictly cognitive but also have a kinesthetic component. The forgetting curve for kinesthetic skills is slightly different and depends heavily on how the skill is learned and practised.

• I don't have quantitative data; I can't just look at the user doing the technique and tell them if they're doing it right or wrong. I can't even look at them, period. I need to rely on their self-reporting of how well they believe they practised the technique.

What data I do have.

I can infer quite a bit of data based on the single rating users give after they have reviewed a technique given in the form of a self-report from 0-100. From this single rating, I store data on; average rating, amount of time successfully reviewed (reviews higher than 65/100. Communicated to the user through the UI), amount of times reviewed in total, user average review score, time since last review and more.

Using this data I calculate a “review score” This is used to rank how well the user knows a specific technique in comparison to their other techniques. Additionally I run a cron job daily that simulates memory decay, this is an exponential function that recalculates the review-score taking into account memory decay over time. The idea being that techniques that you know better will decay slower than techniques that you don’t know as well. That part of the function looks something like this:

In conclusion

This is a hard problem. A problem that might not even have a solution. But for now, I'm enjoying thinking about and working on it. It feels good to have no restraints and take a problem in whatever direction I want to. If you have any ideas or insights, please email me here. I would love to hear from you.

Pre-Session

Designed for use before a training session, this section helps set intentions before a session to help you train with a structured purpose. Features include:

Set your drilling techniques

Here you can set your techniques for the session (what you want to drill/work on). If you haven’t logged any techniques yet go to kenku.org/log-technique to add some of your techniques to the application. Once you’ve done that you can go back and set the techniques that you have saved as things you want to work on in the session. Over time as you log more and review more techniques kenku.org will start to get better at recommending what you should drill based on a spaced-repetition algorithm that models memory decay over time. This is intended to save you from forgetting things and also help new techniques stick faster.

Set your goals

Here you can also set your goals for the training session. If you don’t know what goals to set you can also “generate Ai goals” these can be finicky but get better over time the more sessions you log. Particularly the more you log “things to work on” in your post session.

Post-Session

Here you can record a bunch of data about your session, if you filled out a pre-session form this is the time to reflect on how you went with the techniques you wanted to work on and goals you set. This data will be used in future “pre-session” forms to give you more accurate recommendations for techniques and goals

Here you can also log sparring rounds, you can log quantitative data about the rounds, things like how many rounds you did, how long the rolls were or the intensity of the rolls. You can also log qualitative data about certain positions or certain partners, things like ideas for certain partners in the future, or what you struggled with from a certain position.

At the moment the qualitative data only exists for personal review and can be accessed any time in the “session-bank” section of the application. Eventually I’ll work on drawing insights from this kind of data for you.

Insights

Get quantitative data about your sessions. Can sort by time periods to see quantitative data over a set time period. Things like sessions done over the last month, time spent sparring in the last week, etc.

Log-technique

Used to save techniques, you can add things like tags, concepts and steps to make sure the technique is findable later and also so you can detail every aspect of the technique to make sure your record is accurate. This is editable later so you can always come back and add more detail or change stuff around.

Session-bank

Storage of every session you have ever done, can use the search bar in the top right to find a specific session.

Technique-bank

Storage of every technique you have ever recorded, can use the search bar in the top right to find and edit a specific technique.

Other

Mobile friendly
Unlimited sessions and technique storage for everyone
Secure data, your data is yours and yours only (also feel free to request a copy of it at any time)

Future features

things I am working on or am planning to add in the future

Weekly recap

A weekly recap of your training sessions with suggestions for the next week

What to work on with certain techniques

Based off your comments on reviewing the technique in the past we will give you things you need to work on when you review a technique

Flow-charts

Create flow charts and game-plans with your logged techniques for positions, partners or just in general

Thank You

A huge thank you to all the beta-testers. You make this worth it, thanks for being so patient and kind. Your insightful suggestions blow me away. If you aren't a beta-tester but would like to be one please email me

As a result I’m going back to programming by hand, canceling my gpt-4 subscription and only using gpt as a time-saver for menial tasks, not as something to come up with ideas or write functions for me. Most of the time when I use chat gpt to do things for me it's not perfect but it’s “good enough” and I’ll accept the impacted quality or confusing-roundabout way of doing something for the sake of convenience and fact that I don’t care enough about the sanity of my future self trying to understand what something does.

You might argue that there’s no point in any of this, even learning to program is a waste of time because there's a chance that programming as we know it won't even exist in 10 years. Personally I don’t think anyone can predict the future but even if that’s true I can't imagine any possible future were someone that can think logically, focus for long periods of time and has a strong knowledge of programming concepts (DSA, software architecture, computer systems, etc) will be worse off than someone who doesn’t. If you’re really autistic you can even turn this into a sort of Pascal's Wager

Scenario 1, AI takes over

No change and nothing you did beforehand really matters anyways, do whatever you want

Scenario 2, Humans still contribute to society

Person who actually spent time learning >> smoothbrain prompt engineer

And at the end of the day It’s also just so much more fun and rewarding to program and solve problems on your lonesome, instead of begging some tech overlord to give a coherent answer.

There were a couple things that started to annoy me about developing a tolerance.

• Caffeine was less effective
• I needed a certain amount of caffeine to hit my “baseline”

I realized that if I need something to hit baseline then it’s not really helpful anymore. Sick of my reliance on and tolerance of caffeine I decided to take a two week cold-turkey break from all sources including things like chocolate and soft-drink.

The first few days were surprisingly difficult. I felt like a bit of a vegetable but it didn’t take long (maybe 3-4 days) for my body to adapt and after that I was functional.

Two weeks later I decided to reintroduce caffeine. I had been stuck on a conceptual problem with kenku.org for the last few weeks and didn’t know the best way to solve the problem. Armed with a cup of coffee and hopefully less adenosine receptors I decided that today was going to be the day. I opened my laptop, booted up my editor (vim btw) and started sipping the elixir of the gods. I was ready to get to work. The first sip was a crescendo of pleasure, my senses rejoiced at their favorite molecule entering the system and I quickly had another sip, and another, and another. The coffee didn’t last very long. It only took a few minutes to feel the effects and oh my, was it beautiful. I felt like a cognitive god. I’ve never taken meth but this is what I assume meth would feel like. My brain was running at 100km/h and almost instantly I saw a solution to the problem I had grown so frustrated with. I had spent so much time on this problem that it started to hurt to think about in depth but now it was so simple. I can just do x, y and z and then it’s done, that fixes everything. I instantly got to work and within two hours I was done. What shocked me was how quickly I had come up with a solution, it must have already been at the back of my mind but the caffeine had brought what was in the subconscious into the conscious, I imagine that this is how psychedelics work.

I think that the best thing I did here was that

I went into drinking the cup of coffee with the intention of solving this problem

which i think was super important and something I want to try again in the future.

now that I have less of a tolerance I also want to try to keep it this way for longer so heres

what i’m doing in the future to get the most out of caffeine

• waiting 90 minutes before consuming it in the morning
• not consuming caffeine two days in a row, i can consume whenever i want and in whatever dosage, but I can’t drink caffeine more than two days in a row. I'm hoping this stops my brain from developing too much tolerance. life hack for this. just drink decaf. Not totally caffeine free but has 1/10th of the amount of caffeine and your brain thinks it’s the same thing. Amazing.

Kenku (Currently Beta testers only) is an application that I'm busy developing that hopes to help combat sports athletes better manage their training sessions and streamline their learning and skill acquisition. I see it as a mobile app in the future but for now I'm building it on the web with the SuKit stack (hosted on Vercel) to minimize developer rage and maximize iteration speed. I really believe that iteration speed is everything when building a project, you need to be able to pivot or abandon features whilst losing as little time as possible.

Key Takeaways From the first week

• Nothing feels better than making something, solving problems and being engrossed in a problem for hours on end

• If you think AI is going to replace you, you have a skill issue. Chat-GPT is a child with instant access to the internet who can also talk really fast. It knows a lot but it makes stupid mistakes and often gives sub-optimal solutions to simple problems. I've found using it for anything more than boiler-plate to be more time-consuming than just writing the code by myself.

• You can never go wrong with reading the docs

Things im struggling with,

• UI design. This is hard, like really hard. Going to have to invest a good amount of time into learning how to make an intuitive, user friendly frontend.

• Treading the line between complexity and simplicity. Great software has value in its ability to do complex things, doing complex things simply is the goal but doing complex things simply is hard. It's usually far easier and faster to do complex things in a complex way. Not sure what the solution is here, probably just a skill issue to be honest.

• Direction. It's hard to figure out what features I want to invest the most time into fleshing out. Or what I should be working on at any given moment. Probably need to take some time to really plan out the entirety of the application instead of just having a rough idea in my head.

However I've since matured (marginally so), and now believe that it's sometimes best to throw philosophy out the window if you want to be a functioning member of society. Sometimes it makes sense to have opinions that are rooted in facts. But the problem is that even if you forget the induction, skepticism and the rest of the brain-fuckery, it's still insanely hard to justify any one opinion over another. Who do you believe? Is this food good or bad for me? Is this study method more effective than this one? Should I learn Rust? Ad infinitum. Where do you get your opinions from? How do you know that what you're consuming is grounded in fact and not propaganda. Before I explain my current framework for opinions there's something, you should think about to think about.

An idea that has immensely increased my wellbeing is that you don't need to have an opinion about everything. Sometimes it makes the most sense to just not have an opinion about said thing. There are a number of reasons for this, sometimes it's just not worth the time and energy researching the topic. Sometimes you don't really care about the topic. Or sometimes it's a polarizing topic that you don't want to be on either side of. If you don't feel strongly about a controversial issue, you don't have to pick a side. You can be Switzerland, understand that the issue is delicate and people feel strongly about both sides. Recognize both opinions, but don't hold one in higher regard than the other. There's also a huge social benefit to this. By not having an opinion about a polarizing topic you don't run the risk of adding unnecessary friction between yourself and someone with an opposing opinion. If you don't feel strongly about something what's the point of risking that friction anyways?1

But sometimes you want, or maybe you even need an opinion. I might need an opinion as to whether or not I should take a certain medication, or whether I should put time and energy into learning a new technology. How am I meant to figure out where to get my opinions? I argue that 98.7% of opinions should be outsourced (I made that number up, but it feels about right). You don't have the time to become an expert in everything. If you're lucky you might become an expert at one or two things in your lifetime. So why not just find an expert you trust, and agree with all of their opinions in their domain without resistance. You can assume that even if they're occasionally wrong they're probably going to be wrong less of the time than you are.

• Find someone you think you can trust, who has a substantial amount of experience in the field that you're looking into, but still seems as though they keep up with new developments in their space. This could be by using new technologies, still reading papers or just keeping up with current trends.
• See what people who disagree with that person disagree with them about.
• Decide which side seems as though they have put more time, energy and critical thinking into their opinion.
• Mindlessly make that opinion your own, until it either stops working for you, or more information comes to light

Now you might not like that last point, but bear with me for a second. Unless you're also an expert in that field are you ever going to put as much time and energy into learning about that specific topic as that person has? Probably not. You can also assume that they are as intelligent, more intelligent or at least close to as intelligent as you. So why disagree with them? You can trust that their opinions are well thought out and lay on the foundation of years of work in the field. Years of foundation that you don't have. Make their opinion your own. It'll do wonders for your wellbeing. You no longer have to worry about who to believe or what to think as you've now outsourced your thinking on that topic to someone you know is more qualified than yourself.

For an example of someone I outsource my thinking to. I outsource most of my health and wellbeing opinions to Andrew Huberman. I trust as a phd from Stanford he probably knows a bit more about the human body than me, so I'll trust that what he says is good for me probably is.

Do I see the irony of voicing my opinion on not having opinions? Yes…

When you don’t give your brain any stimulation it starts to create its own. This often manifests as either organizational or creative thought patterns. Only when you’re bored and not being stimulated can you really digest the information you’ve been consuming. You’re forced to think about the things you’ve been avoiding and have no choice but to sort your shit out.

You also don’t need to know more things to have more good ideas you just need to connect what you know in a new way. You’ll notice that a lot of your great ideas happen in the shower, or just before bed. That's because these are some of the only times of the day that we aren’t stimulated and give ourselves time to think. Being bored is what allows your brain to have the chance to use what it knows to come up with new creative solutions and ideas.

Another big thing that I’ve used boredom for is resetting when I find myself either not knowing what to do next or when I’m just fed up and want to stop working. There's a difference between relaxing and rejuvenating activities. and although sitting back and watching an episode of a TV show might seem like a great way to rest after a long study or work block it's actually a horrible thing to do. Sure it’s relaxing, but it's not rejuvenating and afterwards you’ll feel lethargic and won’t want to get back into your workflow, which makes sense. You’re going from an enjoyable activity to a less enjoyable one. But after being intentionally bored for 20-30 minutes you’ll start to miss your work and the stimulation it provides you with. Making it much easier to get back into being productive. This works for almost anything, when you’re doing nothing a lot more things suddenly become more fun than what you’re doing right now. Intentionally being bored is a good way to get yourself to start doing something.

My Current Framework for being intentionally bored

Get a timer, set it anywhere from 10-30 minutes, choose a wall, stare at said wall. Don’t look anywhere but straight and move as little as possible.

I’ve really found doing this a few times a week to be super beneficial for my mental if you found any value from this or want to talk about it, send me an email.

And also great writing advice from Scott Alexander here

I've been blog-curious ever since I found Alex Guzey, but what finally pushed me over the edge was Ben Kuhn's, Why and how to write things on the Internet.

(Both amazing writers. You should check them both out.)
The main points that inspired me were making new, interesting friends that you otherwise would never have access to and creating new and interesting conversations with already existing friends. Getting better at writing was a big plus too.

Another feature of this blog is that it will only use vanilla CSS/HTML/JS (I can't wait to see the abomination I create). The blog will be simple, but I'm excited to see what kind of features I can add all on my lonesome.

Disclaimer!

What lies ahead will be a slew of very average writing from a very averagely intelligent person. Please proceed at your own risk.