04:27 pm, 26 Feb 04
damn i love statically-typed languages
I had been thinking of switching my language-analyzer to use trigrams: basically, tweaking slightly a data structure that's at the core of all of the code, the sort of thing that would give me nightmares when working on (for example) LiveJournal. But all I had to do was (effectively) change
Elsewhere: reading Knuth's TeXbook. Typesetting is hott.
type ngram = (int * int) to type ngram = (int * int * int) and step through the errors. As far as I can tell, it worked perfectly the first time.Elsewhere: reading Knuth's TeXbook. Typesetting is hott.
I would have used a split-bi-gram addressable compound list (a bastardized hashtable). That is, given "AXB", look up list[AB] with the label X and increment the integer associated with it. I was actually thinking of coding this, but i'm lazy and stuff. I really need more than just that anyway, since i want to work with unicode IPA data.
Typesetting is not-so-hot to me, but, you know, more power to you and all =)
I don't follow your syntax at all. Is that the hash "list" keyed by AB? Is that an array subscript?
It's actually a 2-d array like your ruby code, but with the array entries being lists of (character*count). IE: a crappy hashtable. So for [AXB] you'd go to table[A][B], grab the list, look for an entry matching X, if you find one, incr, else add one with a value of 1.
And i think the only reason this is a win for me is because i was going to add a unicode->smaller-numbers mapping step for my array offsets. Doing this saves a lot of room at runtime, especially since i'm only interested in a particular slice of unicode. Though, if you make your mapping dynamic, it's a big win for even diverse input ranges.
It's surprisingly tricky to talk about code you've never written.
And yeah, that does get less practical the more dynamic your language gets. Objective-C is just static enough to let it work well enough most of the time...