Posts Tagged With 'python'
All of my public projects have been suffering, lately (not that I’ve ever been the most constant of writers), because I’ve been working in the background on a tool to aid me in my research.
Some background: Until now, I’ve been collecting my copious notes in wikidPad, a very nice personal wiki application. If all you need is a text-based notebook with some simple formatting and organizational capabilities, it’s great. I recommend it to everyone. My needs are a bit more extreme, though. I’ve currently got notes on about eighteen hundred individual items, along with pages of organizational and planning information. Making use of all the data I have stored in wikidPad was getting to be impossible, and, worse still, some of my notes were scattered in different locations elsewhere due to my needing features not supported by wikidPad.
I’ve tested the various available research notebook tools (Docear, Zotero, Mendeley, ReadCube, Evernote, OneNote, …) but most are heavily oriented toward research artifacts being PDFs (does no one use photographs, or recorded interviews, or anything? just PDFs?), and none had remotely powerful enough metadata and reporting capabilities.
So, I finally bit the bullet and created my own tool. It’s ugly and user-unfriendly right now, but for my purposes it’s already more useful than wikidPad, and I continue adding features as needs arise. The benefit of using custom-built software is that I can readily make any required modifications. If I want to see all of my screenshots of character selection screens for games released between 1987 and 1996, ordered by the name of the developer, with games I’ve never reviewed highlighted in green, I can have that in a couple of minutes. Television episodes about gambling written by people born before 1960? People who starred in movies from the nineties based on games released in the eighties? Games I haven’t beaten developed by defunct companies? Any desired query can be constructed in a few minutes, as long as the information is there. And a lack of information was never my problem.
I don’t know if anyone else would find this useful. The lack of tools that did even remotely what I want seems to indicate that my needs are a bit idiosyncratic. I’ll probably release the code once I’ve got it in a less embarrassing state, all the same.
I mentioned previously that I was working on a fanfiction database. Well, time
for an update: it’s in a functional state, though quite basic. I can feed it a
FanFiction.Net ID and it will download the fanfic and put it in the database
with some very basic metadata (author, ID, summary). Most recently, I’ve hacked
together an HTTP server using http.server so that I can accept commands over
HTTP. Currently, the only command it accepts is ‘add the fanfic at this URL’,
and it just responds with a status page and a copy of the form to add the fic to
favoritestracker. I really should use something a little more powerful than just
http.server.BaseHTTPRequestHandler for this—I really ought to create a
full-fledged web interface, instead of just a commands-over-http hack. But, for
the moment, that’s what I’ve got.
I’ve neglected this blog, which I really shouldn’t have done. Well:
I must reiterate what I said in my last post: when adding tags, I should
definitely specify the revision I want to tag, because I keep making stupid
mistakes, tagging the wrong revisions.
That said, new project:
750-to-org. It’s just a
little python script to convert my 750 Words exports into a suitable format for
emacs org-mode. Nothing special, but I wanted it, so I figured I’d put it out
there in case anyone else might have a use for it. I did learn a little more
about datetime by doing it, too. I doubt I’ll ever remember the meanings of the
tokens for strftime, but at least I know it exists, now. It’s much cleaner that
the way I was going to produce the date strings.
I’ve got a python/sqlalchemy fanfiction database thing I’m making for my
personal use, but it’s far from being in a fit state for public consumption.
More on that later, perhaps.
Well, the bad news is that wordspy still does nothing other than scroll new
lines onto the screen. The good news is that it does it in a better way.
In order to deal with letters dropping (due to letters below them being removed)
at the same time as a new line was scrolling up, it was necessary to re-engineer
the whole thing. Now letters store their current location, and it’s modified
whenever necessary by the newlinescroll and drop actions. This does have some
other benefits, too. For example, it simplifies drawing the new line onto the
screen somewhat. Before, I was doing:
for col in range(10):
screen.blit(Game.letters[6][col].image, (64*col, 481))
Now, since I initialize the letters with their location, I can just do:
for letter in Game.letters[6]:
screen.blit(letter.image, letter.rect)
Which is rather more readable.
Lesson learned, though: don’t forget to empty the dirty rectangles list after
updating the screen. Once it grows to 64 items or so, it noticeably slows down
the game. I’m fairly sure it shouldn’t contain more than a dozen or so items
under normal usage, but I’ll have to remember to keep an eye on it.
Recently, I’ve been looking through a book called Basic Computer Games: Microcomputer Edition, edited by David H. Ahl. The book contains lots of type-in computer games written in Microsoft BASIC for the Altair. A fair number of these ‘games’ are more like toys, and some aren’t even interactive, but a few look like real fun, and they’re all little pieces of computing history, which I find very interesting.
I thought I’d port a few of the more interesting games to a more modern language so people could check them out and see how far we’ve come (or, in some cases, how far we haven’t come). Of course, I thought I’d start by doing exactly what I didn’t set out to do, and port a very simple and not very interesting game, just to get a feel for it. Even this gave me a little pause, as I’ll get into. First, the game: Letter, by Bob Albrecht. That link leads to a scan of (a different edition of) the book I got the game from, so you can see the original BASIC code I was porting. Programmers among us will recognize that it’s extraordinarily simple, and, for a BASIC program, quite clean and readable. One thing gave me a little trouble:
510 FOR N=1 TO 15: PRINT CHR$(7);: NEXT N</pre>
This line didn’t seem to affect the output in the printed sample run of the game, so I got an Altair emulator, just to be sure. Indeed, it doesn’t actually print, though I have no idea why. Whatever the reason, I left it out so as to faithfully reproduce the game as it was on the original system, whatever the code says.
A part of my intention in porting these is to provide sample code for people who may be interested in learning to program; these simple games should prove to be pretty easy to understand for anyone who cares to look. Having just read through quite a lot of BASIC code, I wasn’t in a very pythonic frame of mind when writing this, but I think it’ll be clear enough.
Enough about my troubles, though. You can find the game here. If you have python installed, you can just get the tiny python source file. If not, or if you’re not sure, you can get a ZIP with a Windows executable, instead, which should run on anything from Windows 95 through Vista. If it won’t run, or complains of missing files, you may need this.
I’ll port something more interesting, and hopefully more fun, next time. Until then, I HAVE A LETTER. START GUESSING.
Written by Tracy Poff in misc on Sat 10 October 2009. Tags: python,
I came across an algorithm for computing Fibonacci numbers in a paper by
Takahashi Daisuke; the paper’s in
Japanese, but the pseudocode of the algorithm is plain enough that it’s easy to
understand, even if I can’t read any of the explanation. I’ve implemented it in
python, and it’s decidedly slower than the Fibonacci function in Mathematica,
though that’s to be expected. My implementation takes quite a few seconds to
compute F(2^20) but is quick for numbers below about F(2^15), with the
additional benefits of not computing absurdly huge floats or recursing a million times.
The algorithm is apparently a refinement of another (perhaps well-known?)
algorithm, which computes Fibonacci numbers from the product of Lucas numbers.
I’ll have to look into it to see just how it works.
Edit: After some investigation, a large part of Mathematica’s apparent advantage
is in its faster display, rather than faster computation, though Mathematica
does still beat my python program by a rather huge amount—Mathematica computes
Fibonacci[2^23] in about 0.2 seconds, while my program takes just over five
seconds. This disparity increases as the argument grows larger. Also, found an
English version of that paper. Neat.