A long long time ago in high school, we used the TI-83 Plus as our calculators. These were "graphical" calculators that had small LCD monochrome screens and which could be programmed using the TI-BASIC scripting language. The display itself had various modes, but the default and easiest to access was the 24×7 (I think?) character text console. Being bored at times like I was, I ended up writing various non-school related programs for the calculator, including several games.
The programs themselves did not last long, in part because by default files were stored in RAM and deleted if the calculator was power cycled (the default "on/off" did not clear the RAM, but taking the batteries out would). Eventually we were upgraded to the amazing (or so it seemed) TI-89, which was much more powerful and capable of symbolic equation-solving—thus known as a "CAS" (Computer Algebra System) calculator (and thus, banned in many assessment environments) (but, it still stored programs in RAM by default). This was the end of my TI-83+ programs—though I did write some for the TI-89, which can be found here.
Anyway, to the subject of the post: some time after that
It's gone. It was old (the codebase had barely been updated since 2007), hard to maintain and eventually broke. And that was the end.
All the article content from the site has been imported onto this one, so it is still available, for what it's worth—I really wrote some pretty strange stuff back in the day! The URL structure has not been retained though so it may be hard to find some stuff. Have a browse if you feel like it.
As for what it looked like, before memories of the site are lost to time...
As may be evident, this blog is undergoing some more change. In particular, I have switched to another CMS yet again, this time Ghost. So I have had to redo the theme, and now fix up my content. More to come on the transition once that is done...
Orbiting Earth is just moving sideways so fast that you move away from Earth as fast as you fall back towards it. Just getting up there is easy, but it isn’t enough — you’d just fall straight back down. It’s the sideways speed which is so hard to reach.
You could do this in our atmosphere as well, if the atmosphere wasn’t slowing you down so much.
I was recently party to a very simple, but nonetheless interesting card game. In the game, four players begin the game holding one suit of cards each from a single deck. Then, for thirteen rounds (until the players have run out of cards) every player discards one of their cards simultaneously into the centre, with the player who discards the highest-value card winning the round. If two or more players discard cards of the same face value, then the round is a draw. The winner of the most rounds at the end then wins the game.
While this game is pretty simple and at first glance largely up to luck, it did make me wonder whether there were any strategies that could increase a player’s chance of winning. It would seem so, especially since the starting hands are constant. Therefore, it would be interesting to find both the optimal strategy assuming everyone else plays randomly (i.e. equal probability to play any remaining card), as well as the optimal strategy assuming everyone else plays optimally.
Ever tried to learn Haskell? Confused? Know Python? How about trying to write some functional code in Python? And no, I don’t even mean just using functional principles in Python as the docs describe, I mean actually writing Python like you write Haskell:
def dirty_print (a):
print printr (a)
def printr (a, inside = False):
if type(a ()) is tuple:
lstr = "%s:%s" % (printr(a(),True),printr(a()))
return "(%s)" % lstr if inside else lstr
else: return a ()
base / translation (lots of currying) (also, everything-is-a-function)
needed since Python's basic functions aren't in the `functional' style
_ = lambda n: lambda: n # literal function
multiply = lambda a: lambda b: lambda: a () * b ()
minus = lambda a: lambda b: lambda: a () - b ()
plus = lambda a: lambda b: lambda: a () + b ()
div = lambda a: lambda b: lambda: a () / b ()
gt = lambda a: lambda b: lambda: a () > b ()
eq = lambda a: lambda b: lambda: a () == b ()
flip = lambda f: lambda a: lambda b: f (b) (a)
choice = lambda cond: lambda t: lambda f: lambda: (
t () if cond () else f ()
`lists' (cons cells in Haskell) - we'll use 2-tuples.
# `dirty' (i.e, deal with the underlying data structure)
emptylist = lambda:
Recently, one of my friends told me of her job application, which had been rejected before even the second stage of the recruitment process, which was an entirely automated cognitive aptitude test. I joked that maybe the company randomly sampled their applicants, due to high demand for employment. This made me wonder, however, whether such a procedure was in fact reasonable. After all, processing candidates is expensive and time-consuming, right?
Consider a job application process: there are a certain number of applicants n, of which only some proportion p are “suitable” for the position (in this case, we will consider all suitable candidates equally so). Fortunately, the company only has some t < np* positions open, and thus does not need to find all the suitable candidates. Say they wanted to have a 90% chance of finding at least t suitable candidates — how much of the applicant population would they need to sample?
Of the answer, I’m not sure… perhaps someone can enlighten me. An interesting question though, no?