TheJach.com

Jach's personal blog

(Largely containing a mind-dump to myselves: past, present, and future)
Current favorite quote: "Supposedly smart people are weirdly ignorant of Bayes' Rule." William B Vogt, 2010

Getting started with jMonkeyEngine and Clojure

"I want to write a 3D game in Clojure! But I don't want to bother with raw OpenGL crap, I had my fill of that with Python and PyOpenGL... And I didn't particularly like Panda3D for Python either. I guess I won't be satisfied until I make my own engine one day. But in the meantime, what's a good engine for Java? I remember hearing years ago about something with monkeys..."

That was my thought process a couple weeks ago, and a swift google reminded me of jMonkeyEngine, or JME for short. I had first heard about it back in 2007 or so, but had never played with it seriously. So I figured, why not? Unfortunately I was under some misconceptions that made the introductory period harder. I'll go over the biggest one quickly. JME is better thought of as a collection of libraries rather than a single jar you dump in your project and start building off of. On top of this collection, JME includes a nice IDE and they really want you to use it all together as part of an SDK platform. I really want to use just vim and the command line and treat their stuff as a library. So immediately I'm at odds with the tool, but no matter, it's not impossible to overcome.

Anyway, let's get started, step-by-step. Create your new clojure project with the lein tool:

See Full Post and Comments

"I can understand what each line is doing"

This is typically said of a "simple" language such as C (and sometimes, lately, Go) because the abstraction layer between the hardware and the language is light. If nothing else, you can figure out what's going on at the hardware level if you really want to. (And in Go you don't have to "worry" about the possibility of a macro.) This might help you reason about performance, or understand a disassembled binary, or just as an excuse not to use C++.

A typically response might be "Oh really? What does the line with fnord(i); do?" The correct answer is "It finds the variable i using lexical scoping rules, puts a copy of it in a free register (or pushes it on the stack), and jumps to the location of the fnord function which may or may not use the i value in the register or on the stack, may or may not do something else, and may or may not alter the machine instruction pointer to avoid returning to the jump location like a normal function would."

Okay, but what does the piece of code do? As a programmer reading C code, almost all of my time is spent trying to understand that. Better rephrased, what goal does the piece of code accomplish? I don't tend to care what the machine itself is doing, except in very specific circumstances like optimization and hardware programming.

See Full Post and Comments

1000 Lines

For today's installment of arbitrary thresholds, I bring you this one: before you can even consider yourself a novice in a programming language, capable of doing something useful and capable of offering critique for or against it, you need to have programmed at least 1000 lines of code in that language. If this seems obvious to you, with perhaps uncertainty of whether it's 1000 or 800 or 2000, feel free to quit reading. The rest of the post is devoted to bringing up a few possible objections and hand-waving them away because they don't matter.

First up: lines of code is a horrible metric! Yes, for measuring programmer productivity. But for determining whether you're a n00b or not, I don't think so. If you discover a way to shave off 300 lines of verbose code, replacing it with 10 lines, assume an expert in the language would have seen that immediately. In any case, you win 310 lines in your goal to 1000.

Next up: all programming languages are not equal, what might take 1000 lines of Java might only take 30 lines of Lisp. This is true, and that's why Java is the Enterprise Standard and Lisp is not. It's easier to become a novice in Java than it is for Lisp, regardless of prior programming background. A Lisp "hello world" gives you 1 line in your quest, Java's gives you 5.

See Full Post and Comments

Proofs for and against God

I think I need a simple precursor to my post about proof. This post is meant to destroy the notion that there is anything we cannot prove. I have two preliminary subpoints.

There is no difference between a positive and a negative claim because one can be expressed as the other. I claim "God exists". That is a positive claim. I also claim "God is not nonexistent." This is a negative claim but says exactly the same thing as the first claim.

"Burden of proof" is an expression that signals you are suffering from diseased thinking. There is no such thing as "burden of proof" except in a legal context, where legal proof is the same thing as legal evidence. Proof in general, however, is not the same thing as evidence in general. Much confusion arises from conflating the two. In matters of Truth, there is only "burden of evidence."

See Full Post and Comments

For Else in Python

I have the unfortunate brain wiring where once I understand something complete, or do some task such that it works, that thing suddenly seems trivial to me. I think this is generally true for most individuals who have spent even as little as a year in a narrow field of study, like programmers with a particular programming language. If you're a half-decent programmer, did you know you could make some money by writing a beginner's book? All that stuff that seems trivial to you now, you could monetize! Or be like me and point to other references that are free...

Anyway, the subject of this post. Python has a construct where the for loop or the while loop have an optional else block you can attach to them. The rule that determines whether the block gets executed or not is at first unintuitive, but it becomes immediately clear with an example.

You probably think the else block should execute only if the loop never ran once? If you think that, you are wrong. The rule is: execute the else block if the loop completed normally; that is, without a break statement. (Or raised exception.)

See Full Post and Comments

Conditional probability is the only probability and stay out of the rain

If you have had "normal" math classes, you'll probably be used to seeing entities like "the probability of being struck by lightning." You have probably been misled. For background reference, the number of people who are struck by lightning in the US is about one per million. (They don't necessarily die.)

That's a number. A ratio. A frequency. It is not a probability. Not yet. If you had a normal math education, you should want to argue with me on this point. You were taught that probabilities are just frequencies, which are just facts about the world like the lightning fact. Another number might be two in four balloons are red, in a bag containing two red and two blue balloons.

The lightning number can be turned into a probability, though, provided we provide some conditions. I say all probabilities are conditional probabilities, but you should ask: "Conditional on what?" This depends on the relevant information we have. The only information we have about the one in a million number is that it's for people who live in the US. Thus we might express the above lightning number as $$Prob(being\ hit\ by\ lightning | live\ in\ US) = 1/1,000,000$$. The $$|$$ is read as "given" or "supposing" or "on the condition that the following is true", so you would read that mathematical equation as "The probability of a person being hit by lightning given that person lives in the US is one in a million." But this fact shouldn't make you feel safe if you find yourself in the middle of a nasty thunder storm without shelter.

See Full Post and Comments

Circus Math Considered Harmful

(I always wanted to use that phrase in a title.)

There's a problem with math education. I don't mean a specific field of math, but math in general. At every level of schooling, the problem rears its head. The problem even extends into other disciplines where the math is meant to be a tool rather than the subject.

This isn't a new observation. The problem is recognized by a lot of people, who attack it from different directions. Students claim they don't like "math". How can we get more students to like math? Is it really math they dislike? Or is it just "math"? Teachers claim students are doing worse on tests, so while they're making the tests easier in order to keep their jobs and funding, they ask how can we get students to master more complicated material? Is it really that the material is so hard, or are unrealistic expectations being made, or are artificial barriers being created to buff up the apparent difficulty?

See Full Post and Comments