Unspecified error

Ticked

2011-11-30T19:32:00.000-08:00

It has been ages since I posted anything here. Since today I'm feeling particularly worked up, I've chosen to post the following letter. On the advice of ~~counsel~~ my wife, I've not sent it to Senator Hatch yet, but am waiting to cool off first. Silly me :)

Senator Hatch,

Today you lost any chance at my vote. I admit you'd have lost it already, had I been paying attention, thanks to your support for various ill-conceived and clearly clueless Hollywood-sponsored bills that would ruin (in some cases, have already ruined) the internet for most reasonable purposes; how that I am, indeed, paying attention, your vote today in favor of the National Defense Authorization Act has sealed the deal (side note: I'm moderately surprised I'm actually linking to the Huffington Post...). You have proven yourself ignorant of the value of due process yet once more. Senator Lee, who struck me during his campaign as little more than "full of sound and fury", has proven himself intelligent and reasonable on the issue, having obviously made the realization you have yet to grasp, namely that indefinite imprisonment of United States citizens, captured on American soil on potentially unfounded suspicion of terrorism, is in violation of the due process guaranteed by the Constitution, and cannot be legislatively endorsed under any circumstances.

Perhaps you think that such a scenario, although allowed by the act I mentioned, is too unlikely to be worth considering. That may be, but that's not how laws work. Correct and just laws prohibit the wrong, and allow everything else. Perhaps you think a citizen imprisoned under this act would be released after judicial review, because of its clear Constitutional violations. That may also be, however the point is to write decent laws in the first place, not write lousy laws and make the courts correct them while bankrupting the poor soul who first contravenes the idiotic legislation you've cooked up. Furthermore, Constitutional violations aren't exactly a new thing in the federal government, as you well know, and it's entirely likely that yet another such violation would be justified by some twisted logic or other, as so many others already have been. Perhaps you think that only the truly guilty would ever be thus imprisoned. That may be, but there's still a reason we have due process. Considering the Dept. of Justice regularly describes as potential terrorists people who own firearms, possess survival skills, say nasty things about government policies, and keep food storage, I'm unconvinced the terrorist witch hunt won't catch plenty of innocents in its net. By that description, most of my neighbors and the vast majority of your constituents are already possible terrorists.

I hesitate to use the word, but in this case it applies: this has me outraged. My vote, and those of anyone I manage to influence sufficiently, will go elsewhere.

Today

2011-05-21T18:55:00.001-07:00

I planted corn today. I also helped with a move, biked a bit, and learned a few things. But whatever rapture may have happened left me behind. Should I feel accomplished, or not?

Sprouts. Lots of sprouts...

2010-04-26T21:52:00.000-07:00

I was tempted to take a side trip with the boys to the garden last night. It didn't happen due to time constraints, but the temptation was there, Had I gone, I probably would have found the lovely site that awaited me this morning: all kinds of little baby plants coming up. We've got peas a-plenty, and radishes and lettuce all over. The leeks appear still to be going strong (rumor has it that to get big leeks, you let them overwinter; I have my doubts that this batch will live to see that day), but no bean sprouts yet... unless the evil quail have stolen them. Also no dill nor fennel, but given that my seed stock dated from 1996, I'm not terribly surprised.

...and beans...

2010-04-17T20:54:00.000-07:00

Today we planted beans, and scattered a few more leek seeds to round out those that volunteered from last year. I have high hopes for both leeks and beans, as they come from seed we've saved from last year (or possibly, in the case of the beans, the year before), and because I'm a fan of both of them. Karlyn surprised me with her hearty endorsement of our salt-preserved beans; hopefully we'll end up with bunches of them this year, though if we finally sell our house and move elsewhere, that may become difficult.

We also took the time today to hoe up the remaining maple tree volunteers, and among their remains, to my dismay, I discovered the first of the year's morning glory. The bane of all Salt Lake City gardeners, it has apparently wasted no time getting going this spring. Fortunately the rhubarb isn't yet big enough to have overgrown what are usually the morning glory's best defended strongholds, so we have a few more weeks to really nip it in the proverbial bud, before having to cede vast swaths of formerly fertile garden to its persistent grip.

I realized today that the quarter of a beef we bough in January has lasted us approximately one quarter of a year thus far, with plenty to spare. Realizing that when we have our own cow(s?), the calves they provide will be far smaller than the full grown beef that filled our freezer, it's still nice to think that in at least some of those years our cow provides us with a male calf (we'd likely sell the females), we could accompany it with a pig or two and several chickens, and be entirely set for the year's meat supply. This doesn't necessarily relate to the garden so much, but it's a comforting thought, and bore recording.

Ooo... rain

2010-04-11T10:43:00.001-07:00

Being of a curious nature, I eventually checked the expected weather for the next few days. And indeed, it is supposed to rain (not that all the wind this morning isn't enough of a sign already). My seeds will be happy.

Peas

2010-04-10T20:36:00.000-07:00

I haven't used this blog thing for much lately. Various friends and family blog, and sometime I think I ought to join in. I haven't made the leap yet, though, and in all likelihood I probably won't.

The blog is about the most suitable tool I have right now for one specific purpose, though. As we've been working on moving to a new house, one with a few acres we hope to grow stuff on, I've realized we'll need to do a fair bit of experimentation as we learn how properly to handle a more agricultural lifestyle, and it will be critically important to keep notes. Eventually I'm kinda thinking of applying some database technology I've been hoping to experiment with anyway, and writing my own program to handle those notes, but I've not done that yet. Instead, I'll use the blog.

So here goes. Today we planted "Early Frost" peas. This is the second planting, as the first germinated less than enthusiastically. Grandma says peas in particular need to be planted more deeply than one might expect, because they work themselves out of the ground and die if they're too shallow. Of the two initial rows, one has germinated about 60%; the other was a complete dud. So after pulling out about a billion little maple seedlings, we replanted. There's a reason they recommend composting leaves before digging them into a garden, but we didn't have that luxury; last fall we tilled in a bunch of leaves and a little fertilizer.

Karlyn and I seem to have different ideas about what it means to plant "a ton" of peas. Every year we've grown a garden, we've had a couple scraggly pea plants and enough peas that everyone in the family got one or two pods before it got too warm and the plants died, and every year we've thought "next year we'll grow more." And we have done that, but in my view, not enough more. So in the place Karlyn put two rows, I put four, and used up the package and a half of seed we had remaining.

Today we also planted a bunch of radishes (we've always thought of planting those, but never gotten around to it), two kinds of lettuce (head lettuce, and a leaf lettuce mix), and some dill and fennel. These last two sound really neat but the seeds were packed for the 1996 season, so they may not do so well.

All the plantings are covered, the peas with a garden blanket, and the rest with wood-and-wire-mesh cages. Per instructions from Grandma we haven't watered yet. Hopefully we'll get some rain in a few days (I've no idea what the weather man has to say about that; I'd just like some in a few days), or we'll start some light watering.

The boys really enjoy digging. Just not where they're told to dig.

Electronics is fun

2009-06-28T15:39:00.000-07:00

Those with a passing familiarity with electronic components will, in all likelihood, consider this just plain silly. However, as I have long had an interest in electronics combined with an apparent irrevocable curse when it comes to actually building a working circuit, I found this experience comforting and inspiring.

Central to modern electronics is a device called the transistor. It allows a small current to control a larger one, which essentially means it's an amplifier.

The upper of the two schematics below shows a circuit that doesn't work. Your skin allows small amounts of current to pass, but if you hook your skin to a 5 volt power source, the current coming out of it won't be enough to light an LED. The second schematic, though, is the one I just built, and shows a transistor in action. The fact that it actually worked still makes me grin. For that matter, it also got Andrew fairly excited -- he likes that kind of thing.

The working circuit allows the tiny current from your skin into a transistor. That convinces the transistor to allow lots of current through, which is adequate to light the LED. Better still, the tighter you grab the wires, or the wetter your hands, or in short the better a conductor you are, the brighter the light gets.

Now what I'm not sure of is why this works when I only grab the wire going into the transistor. I don't even have to is greater than my power supply's ground potential. I haven't seen it light up brighter when I shuffle my feet on the carpet; that would be cool :)

Update: Ok, I do know why this works -- the ground potential here is more positive than the ground potential in my power supply, which in turn is based, I guess, on the neutral level at the power plant (my power supply doesn't use the ground plug in the outlet here). So current flows from me and everything else to the power plant even if I don't hold the positive wire.

More kids' stuff

2009-06-17T07:59:00.000-07:00

This was fun.

Kids are cute

2009-05-03T21:04:00.000-07:00

By popular demand, here are kid pics. Aren't they fun? Also, a video.

PL/LOLCODE commit

2009-05-01T20:13:00.000-07:00

I've just finished another commit to PL/LOLCODE. It's a beautiful thing. That is all. :)

More geeky database stuff

2009-04-28T14:42:00.001-07:00

I tend lately to post geeky stuff on the company blog instead of here. Those interested should refer to this page to see the latest on that front.

Spread the Joy

2009-03-26T04:33:00.000-07:00

With my day job comes the opportunity to create posts on the company blog. It seems of more value to the company if I put database-related techie nerd posts on their blog rather than on this one, and the value to me is probably sixes either way. That said, this blog post simply serves as notice to those few (approx. 1) of my many readers (approx. 2) who care about such things that there's a new database-related techie nerd post available for perusal.

Fun With SQL

2009-03-14T22:40:00.000-07:00

Later this week I'll be presenting at the Utah PHP Users Group meeting about neat stuff you can do in SQL. I've finished the first draft of the slides, here.

I'm not much of a PHP fan, and not necessarily always quiet about that fact, so extra thanks to mindjuju for the invitation.

Lily videos

2009-02-22T10:01:00.000-08:00

Doting parent that I am, I couldn't rest until I got this videos posted. Well, ok, I have a newborn, Karlyn's stuck in bed most of the time, and the boys are sick, so I haven't been able to rest anyway. But here are some videos.

Baby's here

2009-02-21T09:26:00.000-08:00

After nearly two weeks more waiting than we originally expected, Lillian Elizabeth was born Wednesday, and I'm getting around to posting pictures, here. More from a very helpful sister and brother-in-law, here.

Lily weighs about 0.68 stone (66,500 grain, 0.13 talents) and is a little over one cubit long (about 1/400 of a furlong).

Unrelated note: This is a fun online unit conversion utility.

Slony1-2.0.0 + PostgreSQL 8.4devel

2009-02-02T12:15:00.000-08:00

Excellent post, if I do say so myself, from the End Point blog about using Slony1-2.0.0 and PostgreSQL 8.4devel. Enjoy.

I CAN HAS SQRT?

2008-12-18T05:48:00.000-08:00

I was pointed at this today. Although it doesn't follow the LOLCODE spec as I read it (perhaps it follows some consensus about future specs that I've not paid attention to), it's neat: square roots in LOLCODE.

ForwardAgent

2008-12-12T22:55:00.000-08:00

Periodically I'll learn something so useful I immediately wish I'd known it years ago, and so simple I'm almost ashamed to admit it was news to me. UNIX systems in general, and Linux in particular, seem to be especially good at coming up with such things. Yesterday was one such experience, when I learned about SSH's ForwardAgent option.

SSH agents let you use passphrase-protected SSH keys without typing in your passphrase all the time. If I connect from Host1 to Host2 via SSH, Host2 sends me a key challenge and my SSH agent answers it authenticate me. But if I then use SSH to go from Host2 to Host3, by default I need to either type a password on Host3 (which is annoying and not terribly secure) or copy my private key to Host2 (which is annoying and terribly not secure) (yes, I meant to write it that way).

ForwardAgent (configured in ssh_config) allows Host3 to send a key challenge to Host2, and Host2 to forward the challenge to the SSH agent living on Host1. It's as if my private key followed me wherever I went. Neat :)

Woah... a MUMPS person

2008-12-11T22:38:00.000-08:00

Yesterday, on the bus, I found out an otherwise unassuming acquaintance who works at the local veterans' hospital, is a devotee of the VA's VistA health information system, and the MUMPS system that supports it. I knew there were people still forced to use MUMPS; I didn't know anyone actually enjoyed it.

The VA open sourced VistA while I was working in medical software. I spent a few hours typing inscrutable strings of strange characters into an only semi-responsive console before giving up with the conclusion that anything that esoteric wouldn't be much of a competitor to our product. Which is not to say our product actually worked, just that it was easier to install.

New sourdough starter

2008-12-07T10:28:00.000-08:00

We like sourdough. It's neat, it's fun, it's yummy... but we've had problems with sourdough starters. I got a sourdough start from a coworker a while back. It came with a pedigree: a settler had started it over a century before in the Joe's valley area of Utah, and it had been shared and passed down through families ever since. This coworker grew up on sourdough pancakes from this same starter. For a while it worked well, and even when we didn't remember to treat it kindly, it still made decent bread. We learned that even though we couldn't see the difference between quality wheat and crummy wheat, the starter could, and flour from good wheat would rise better. We learned that the electric flour mill we used heated the flour too much, and the starter wouldn't grow well, and when we finally got our manual grain mill the starter worked much better. But eventually the starter just got nasty. Sourdough recipes talk about a "pleasant sour odor" but ours was far from pleasant. It was more like sour feet than sour dough.

So we started a new one. It's easy enough -- mix flour and water and let it sit out for a few days, periodically adding more flour and more water, and occasionally changing the bowl it's in to a nice clean one. Cheesecloth or perforated plastic wrap on the top is good for letting wild yeasts in and keeping bugs out, and in a few days you get something kinda foamy. That starter worked decently enough, but since last summer we've been fairly busy, and haven't been able to feed it regularly. So the other day we retired it from its dark corner of the refrigerator where it had spent the last few months, and I ground up some rye to start a new one.

Rye is supposed to be better than other grains for starting sourdough cultures, because it has less phytic acid than other grains. Eventually we'll have to -- gently -- introduce wheat flour to this starter; it takes a while for a starter to make the transition to a new flour. But for now, we've got a pasty flour blob sitting in a bowl showing faint signs of bubbling. This being winter, the wild yeasts we collect aren't as active and our kitchen counter isn't as warm, so it takes a while for it to get started, but here are some pictures, just for kicks...

Cross-column statistics III

2008-11-14T01:23:00.000-08:00

I'm hoping, possibly in vain, that in this post I'll actually get to the point I was hoping for when I started these posts (previous editions available here (part 1) and here (part 2). This wasn't originally supposed to be a series, much less an epic.

The last post introduced a few questions we need to answer in order to implement cross-column statistics, and got as far as demonstrating how PostgreSQL uses histograms and why it assumes columns are independent. Again, this assumption stems entirely from the fact that the planner has no better information go on, not because it's a particularly correct assumption. As an example, height and weight of an individual are fairly closely correlated values; people who are relatively tall tend to be relatively heavy. In statistical terms, they're "dependent random variables". But since PostgreSQL doesn't know that, it can't make query plans that take advantage of the fact.

There has been a fair bit of study into modeling the dependence between random variables. Some go so far as to say dependence is the most studied topic in statistics[1]. So there are a few different well-studied ways of modeling interactions between database columns. But the simple histogram method used for single columns probably won't work, for several reasons. Principle among them is what's called the "curse of dimensionality"[2], which says in effect that as you add more and more dimensions (in this case, columns) to a dataset (in this case, a histogram), the volume of the space increases exponentially, but the amount of data available to describe that space doesn't, so the details of the space are less and less defined as dimensions are added.

There are other ways. Right now I'm interested in what's called a copula[3], suggested on the pgsql-hackers list by Nathan Boley. A copula is a function defined on the domain [0, 1] in multiple dimensions whose arguments are uniform random variables. Assume we are given two random variables x and y, drawn from populations X and Y respectively, and functions F(x) and G(y), where F(x) gives the percentage of members of the population X that are less than the value x, and similarly for G(y). In our application, X could be all the values from one column of a table, and Y could be all the values from another column in either the same table or some other table. Existing histogram techniques allow us to determine F(x) and G(y). Our cross column statistics are trying to give us a value for H(x, y), which is the proportion of the joint population X + Y whose values are less than both x and y. For two variables, Sklar's theorem[see 3, again] states that H(x, y) = C(F(x), G(y)), where C is a copula.

So what's so neat about copulas that we'd want to investigate them? Perhaps most important is that they help overcome the curse of dimensionality. They model a probability space, not a population space, and every new dimension you add to a copula is defined across its entire probability. Just think about that one, because I can't figure out how to explain it better. That's a blow to my ego, but a blessing in that it means this post won't be as long. :)

Copulas (or if you want to be pretentious, copulae) are also interesting because they're getting a lot of attention, which means there are people figuring out how to use them effectively (which is nice if we want to use them effectively within PostgreSQL). Economists and actuaries and the like use copulas a lot to model interactions between variables so they can tell you, for instance, how much they're raising your insurance premium.

All that said, if we decide copulas work to model this stuff, there will be a bunch more questions to answer:

1) What kind of copula will we use? There are lots to choose from, with names like "Ali-Mikhail-Haq" and "Farlie-Gumbel-Morgenstern"
2) How will we store the copula in some quickly usable but not terribly huge format?
3) How will we actually use these things, anyway?
4) Which columns will we store this way?
... and lots of others.

Finally, by request, an almost entirely unrelated point.

[1] K. Jogdeo, Dependence, concepts of. in: Samuel kotz, norman l. johnson, and campbell b.
read, Encyclopedia of Statistical Sciences 2 (1982), 324–334. as cited by
Ioannidis, Christos and Williams, Julian M.,A Black Box Approach to Copulas: The Non-Parametric Empirical Copula Approach. Available at SSRN: http://ssrn.com/abstract=955493
[2] http://en.wikipedia.org/wiki/Curse_of_dimensionality
[3] http://en.wikipedia.org/wiki/Copula_(statistics)
[4] http://archives.postgresql.org/pgsql-hackers/2008-10/msg00865.php

Cross-column statistics II

2008-11-06T05:27:00.000-08:00

My last post talked generally about how PostgreSQL uses statistics for query planning, and was written to introduce the topic of cross-column statistics, in which I've long been interested. This post will blather on for a while about what such things are, and why they might be neat. Or it might end up being more on single-column statistics, because a basis in one-column stats is useful for understanding cross-column stats.

PostgreSQL's statistics are kept for each column, and each column's statistics are independent of those for another column. The planner assumes that the data in one column are independent of the data in another column; that is, that the probability of a particular value showing up in a given column and row is independent of the other values in the row. The planner makes this assumption not because it's reasonable (it's not), but because it's a lot of work to do otherwise. In order to get past this independence assumption, the planner would need to keep "cross-column" statistics, or statistics that model the interactions between values of different columns.

There are a few questions to answer when considering implementing something like this. They include:

What statistics could we keep that would improve query planning? In other words, what statistics can we use?

How can we keep those statistics without taking too long to build them, too much space to keep them, or too long to use them when planning queries?

How do we know which columns have interesting interactions? In other words, which are dependent enough and involved in enough queries together to make it worth tracking their interactions?

Does this work for columns that are part of the same table, or can it work for columns in different tables, joined by some defined relationship?

What statistics could we keep that would be useful?
To answer this question, it helps to know how PostgreSQL uses its current statistics. Remember that the point of keeping column statistics is to estimate the number of rows in the column that meet a given condition, such as "LAST_NAME = 'Heiseldorf'" from "SELECT * FROM PERSON WHERE LAST_NAME = 'Heiseldorf'". To answer this question, PostgreSQL keeps several statistics values for each column, including:

the most common values in a column

the number of distinct values in the column

the fraction of NULL values (NULLs are often treated separately, as it's reasonable to assume the distribution of NULLs would behave differently than the distribution of other values)

the most common values in the column and their frequencies

a histogram describing the distribution of values in the column. "Histogram" means different things for different people; in this case it's a list of the 1/Nth quantiles, where N is the column's statistics target value. In other words, if statistics target is 10, this will include a list of 10 values in order. The first value in the list is greater than 10% of the values in the column, the second value in the list is greater than 20% of the values in the column, and so on.

The planner can use these values to approximate the number of rows where a particular column's value is equal to, greater than, or less than any other given value. For instance, to find how many values in a column equal "Foo", the planner will look for "Foo" in the most common values list. If it finds it, it uses the estimated number of total rows in the relation (pg_class.reltuples) and the estimated frequency of that particular value (available in pg_stats.most_common_freqs) to guess the number of rows containing that value. If the value isn't in the most common values list, it assumes it's uniformly distributed with all other "less common" values. For inequalities (e.g. "WHERE some_field < 'Foo'"), it looks through the histogram buckets to find which one contains "Foo". Assuming it finds "Foo" in the 5th bucket, it knows "Foo" is greater than all the values in the first four buckets. If there are 20 buckets (e.g. statistics target = 20), that means "Foo" is greater than 4/20, or 25% of the rows in the table. Multiplying by pg_class.reltuples gives the number of rows the inequality operator is expected to return. For data types where a distance metric exists (like numeric values, where it can use the subtraction operator), PostgreSQL can assume a linear distribution of values in the histogram bucket and get a presumably more accurate estimate. But this can only work if the data type's values are from a metric space, that is, where there's a distance metric.

Trying to extend this idea into multiple dimensions quickly becomes difficult, especially when one remembers that it has to apply to data types without a distance metric. If everything had a distance metric, we could (for instance) divide the space between the maximum and minimum values in each column into N uniform segments (N again represents the column's statistics target), create a P-dimensional matrix (where P is the number of columns involved) with N^P cells, where each cell contains the count of rows whose values fall within the histogram bucket defined by that cell.

This approach is simple, but fails miserably in practice. For starters, as you add columns to the mix, the number of histogram cells goes up exponentially. Also, this falls victim to the "curse of dimensionality"; put simply, although the size of the matrix increases exponentially as you add columns, the amount of data does not increase, so the amount of data in each part of the matrix decreases, until it's so small that you know effectively nothing about most of the matrix, and it becomes useless for estimation.

Further posts will explore more of the questions above, as well as ways to implement cross-column statistics.

Cross-column statistics

2008-10-20T16:26:00.000-07:00

Of late, I've been involved in an interesting thread on the pgsql-hackers mailing list regarding cross-column statistics. I can admit no immediate personal use for such a feature, but that hasn't stopped me before (cf. PL/LOLCODE), and it's a very interesting subject. I'm blogging about it because, well, I can. I expect, though, that my kids won't let me finish it all now, and that this will be a multi-part post.

The idea of planner statistics on single columns is well understood and implemented all over the database world. That's what you run ANALYZE for -- to refresh those statistics. Ideally the statistics the database keeps will help it determine the best way to execute queries. For instance, assume you have a table called PERSON which stores FIRST_NAME and LAST_NAME, with an index on both columns, and you tell the database to SELECT * FROM PERSON WHERE FIRST_NAME = 'Alfred' AND LAST_NAME = 'Heiseldorf'. The planner can choose several different ways to execute this plan. It can:

Scan the entire table and check each row to find matches to the query

Scan the index on FIRST_NAME for 'Alfred', and scan the results for LAST_NAME = 'Heiseldorf'

Scan the index on LAST_NAME for 'Heiseldorf' and scan the results for FIRST_NAME = 'Alfred'

The planner has to choose which of these three options would be the fastest, and to do that it has to guess how many rows are involved in each method -- hence the statistics. PostgreSQL keeps track of, among several other things, a list of the most common values in each column, and what percentage of the table each comprises (most_common_vals and most_common_freqs in pg_stats). The length of each list is determined by the statistics target value for each column (or default_statistics_target if a target for that column is not specified). PostgreSQL will look at the statistics for the FIRST_NAME and LAST_NAME columns to see if 'Alfred' or 'Heiseldorf' are in the lists of most_common_values for their respective columns. See here for more specifics, but using these values, along with estimated numbers of rows in the table, the planner can guess that there are, say, 310 'Alfred's in the table and 4 'Heiseldorf's. In that case, the optimizer will probably choose to look for 'Heiseldorf' first using an index scan on the LAST_NAME field, meaning it will have to scan only those four rows looking for 'Alfred's.

There are lots of other details, and to avoid being too long (but mostly to avoid embarrassing myself by getting them wrong) I'll leave them out. Suffice it to say that having good guesses about the number of rows a query will return is important for getting decent query plans.

More on this subject later...

Calculating pi in LOLCODE

2008-10-12T11:35:00.000-07:00

Magnus Hagander asked me for a simple function to return a number using PL/LOLCODE. Here's a pi calculator, based on a post by Grzegorz Jaśkiewicz on the PostgreSQL GENERAL mailing list showing how to find pi using PostgreSQL's new recursive query feature:

create or replace function lol_pi() returns float immutable language pllolcode as $$
HAI

I HAS A PIADD ITZ 0.0
I HAS A PISUB ITZ 0.0
I HAS A ITR ITZ 0
I HAS A ITRZ ITZ 20000
I HAS A T1
I HAS A T2

IM IN YR LOOP

T1 R QUOSHUNT OF 4.0 AN SUM OF 3.0 AN ITR
T2 R QUOSHUNT OF 4.0 AN SUM OF 5.0 AN ITR
PISUB R SUM OF PISUB AN T1
PIADD R SUM OF PIADD AN T2
ITR R SUM OF ITR AN 4.0
BOTH SAEM ITR AN BIGGR OF ITR AN ITRZ, O RLY?

YA RLY, GTFO

OIC

IM OUTTA YR LOOP
FOUND YR SUM OF 4.0 AN DIFF OF PIADD AN PISUB

KTHXBYE
$$;

select lol_pi();

UPDATE: Fixed indenting to make this look nicer, and credited the mailing list post
UPDATE PART 2: Note that this particular function doesn't use anything special about PL/LOLCODE, and AFAICS should run just fine in any LOLCODE interpreter.
UPDATE PART 3: Note also that there are better facilities for loops in LOLCODE, but PL/LOLCODE doesn't implement them yet, which is why I've got to track the counter explicitly, and explicitly GTFO when it hits ITRZ.
UPDATE PART 3: Some investigation has revealed that this method of calculating pi is called a Gregory-Leibniz series

PL/LOLCODE HOWTO

2008-10-08T14:34:00.000-07:00

I'm working on a presentation for this weekend's PostgreSQL Conference. It's 90 minutes of me chatting about turning LOLCODE, of all things, into a PostgreSQL procedural language.

Why You Should Consider PostgreSQL

2008-09-15T22:48:00.000-07:00

I'll be presenting at the Utah PHP Users Group (UPHPU) this Thursday on PostgreSQL. I'm not much of a PHP person. The last time I used it heavily was shortly after PHP5 was released, and I found between changes I had to make to get PHP4 code to work in PHP5, plus frequent security patches I had to install, plus changes I had to make to get my code to work with the patched PHP, it was all more work than I felt I wanted to endure. So I switched to Java. That was also an inappropriate choice for many reasons, but it was an excellent introduction to the sorts of things the programmers were doing at the job I started around that same time, and since the project for which I was doing all this programming never went anywhere anyway, it's probably all for the best.

Anyway, I met "mindjuju", the president of UPHPU at the recent Utah Open Source Conference, and since I'm president of the Utah Database Users Group we started chatting user groups. We're trying to get UDBUG off the ground, and since most of our membership is already involved in other users groups, we figured one way is to have meetings in conjunction with other groups.

A few days later, I got a message on IRC from mindjuju suggesting that, as I'd expressed my devotion to all things PostgreSQL to him at UTOSC, I might want to do a presentation to introduce people to PostgreSQL and let them know why they might want to use it. Another message a few days later told me that the scheduled presenter at this month's UPHPU meeting might have to cancel and could I step in if that happened. Hence the talk, the first draft of which is above.

Schematic, etc.

2008-09-14T14:38:00.001-07:00

I'm hoping to get this blog caught up with the current state of the project, and as such, have spent the last $way_too_long messing with KiCad to draw a workable schematic of what I plan to do. See the image associated with this post for the somewhat disappointing results. KiCad made a nice postscript schematic, but I had to settle for a ATmega8 in the image instead of the ATmega168 I'm using, and the multiplexers I've got aren't the 74LS154s shown, because of limitations in the KiCad component libraries such as they exist on my laptop. Also, blogger.com wouldn't, so far as I could see, allow me to upload the original postscript, so I've had to convert it to PNG, with a fair bit of lost resolution as a result. Anyway, the idea is that the microcontroller counts, as quickly as possible, from 0 to 255, and puts the value out on PORTB, four bits of which act as the selectors for each of two 1:16 multiplexers. One multiplexer has a constant +5V input, and it electrifies one of 16 possible rows in a matrix of switches, depending on the selector values from the ATmega168. Then the other multiplexer, whose selectors are the lower four bits of PORTB, iterates through all 16 columns of the matrix. The output of that multiplexer goes to a pin on the microcontroller; if a charge manages to show up on that pin, the microcontroller knows that a switch has been pushed. The software on the ATmega168 will keep track of what keys are pushed at any given time, and when something changes, will send a signal to a computer somewhere. Here's hoping it actually works.

The multiplexers are really neat. In this project, they serve simply to give me a bunch more pins to work with. You can put a signal on its "input" pin and send it to one of 16 possible outputs by applying a binary number between 0 and 15 inclusive to the four selector pins. They also work in reverse, so if you're applying signals to the 16 pins, you can choose which signal ought to be fed out of what would then be the "output" pin. That lets me control a 16x16 matrix of 256 "switches" (the organ pedals, keys, and whatever else I want to control) with only eight microcontroller pins to selecting the switch I'm interested in. I feed +5V into one multiplexer constantly, and use one more microcontroller pin to see if that +5V gets through the switch matrix to tell me a key is pressed. Quick thanks to Intersil for sending me two free 1:8 multiplexers (three selector bits, eight possible outputs). If I don't find a place for them in this project, I'll find a place in another project :)

Yesterday I soldered together a 5V power supply with pretty much the schematic shown here. Now my test circuit on a breadboard on the floor next to the baby cradle behaves predictably :)

Background

2008-09-09T04:20:00.000-07:00

I started this blog principally so I could document projects I'm working on, or thinking of working on, or concluding not to work on, etc. Principle among these is the organ I'm hoping to refurbish. One Christmas, my grandma called me to say that an aunt of mine was getting a new organ for Christmas (similar, if I remember correctly, to this one, giving her old one to grandma, and would I like grandma's old Hammond that's been sitting in the basement for years (similar to this one), and kinda still works?

I said yes, and with much grunting, straining, and herniating, we got the thing up the stairs and into my second floor condo, whereupon I discovered what little it could do. Half the time it doesn't even turn on, and the sounds it makes are pretty rough. However, thanks to a nice, open source, software organ synthesizer called Aeolus, my computer can do a decent organ impression. So I figured I'd build a MIDI interface into my new Hammond, whose console is pretty decent, internals notwithstanding, and via MIDI the console could tell my computer what sounds to make.

So I started learning electronics. It's loads of fun -- I've wanted to learn this stuff for years anyway, and now that I have a real project to apply it to, I find it's not too tough. Yet. :)

Why?

2008-09-08T20:10:00.000-07:00

Someone asked me today, "Are you blogging this somewhere?" Having never felt the need to start a blog, much less update one (regularly or otherwise), I was somewhat taken aback. Who, after all, could possibly be interested, and if no one was interested, what difference if I just stick to scribbling occasional poorly composed ramblings into my neglected journal while slumped listlessly in a chair at the kitchen table at 4:00 AM, having once again allowed the nocturnal demands of my two little boys to chase from me all capacity for more sleep?

Whew... take a breath...

The answer: The Greater Good. Or perhaps not. In fact, it has been suggested that some of the activities I've seen fit to engage in (or to make vague plans one day to engage in) might prove useful or interesting or something to various denizens of the InterTubes. Not only that, I realized that my embarrassingly spotty journal writing habits didn't lend themselves well to the strict documentation required by experiments such as I intend to conduct in relation to the above activities, and that perhaps the convenience of blogging would somehow encourage more consistent record-keeping.

If you've made it this far with some measure of comprehension, my congratulations to you.

In short, I'm writing this because someone suggested they might be interested. That being the case, I'll try to ensure that the stuff I post aligns with the expressed interests of my readers, such as they are(n't). Should I fail in those efforts, well, phooey.