Lazy programmer – 6/12/2006 10:44:41 PM
Once I saw an upperclassman editing a very large text file. It turned out that he was removing unwanted lines. The unwanted lines had a clearly defined pattern, but instead of making a program to remove it, he scanned the lines one by one.
He could program, but didn't use his programming skill. Sure, we don't need to make a program for every imaginable trivial task. However the text file which he edited was so large that the benefit of making the program would clearly outweight the cost of making it. A lazy programmer is not a programmer.
There are lots of small disposable programs on my disk. Some examples are:
- A program to append a string to all file names on a folder (I once needed to rename hundreds of file)
- A program to modify each line of a text file in various ways in which new modifiers can be easily added (the need to manipulate strings in a text per line happens really often)
- A program to correct broken links created by a stupid program called WebCopier
That is because when I am faced with a repetitive task which can easily be programmed, I don't hesitate to make the program. I'm a strong believer that uncreative jobs are better left to machines, while humans better spend their time for creative endeavours.
SharpJiten 1.0 RC – 6/12/2006 10:12:01 PM
The program is essentially complete. On the screenshot you can see SharpJiten set to synchronize itself with the clipboard and additionaly only displays grade 1-3 kanji. When a bunch of kanji is copied from a Wikipedia article, the program updates itself and displays the relevant kanji.
What remains is tyding the code (throwing unused commented code, for example) and modifying the program to use an internal (embedded) EDICT instead of a separate EDICT file. Oh, and some days of bug testing to make sure that nothing silly happens.
SharpJiten is a memory hog – 6/12/2006 8:42:02 PM
SharpJiten is the name of the kanji dictionary program I'm building.
On the previous build, SharpJiten only loads some essential kanji info from EDICT. Those fields are the kanji itself in Unicode, (Japanese) readings, English meaning, stroke count, and grade info. This results on a memory footprint of around 26 MB.
However, EDICT has additional fields, more than what you can imagine. Some examples are SKIP code, various printed dictionaries' index, and Korean reading. When all fields are loaded, the memory footprint blows to 40 MB. As a comparison, Wakan requires around 37 MB and JquickTrans 14 MB. The memory usage of JquickTrans is amazing, considering that it is both a kanji and word dictionary.
The EDICT specification specifically states that any fields can be added at a later specification. SharpJiten will have a custom filter in which the user can specify arbitrary field to filter. This makes SharpJiten forward compatible with future versions of EDICT.
About the memory usage, I won't fuss over it. Deadline is approaching (when is it anyway?) and my priority is to have the program working. The only feature not implemented is the arbitrary field filter thing.
Yomiuri Meijin – 6/12/2006 5:38:01 PM
The Meijin is historically a title for the strongest Go player on Japan. Then the title was transformed into a prestigious tournament sponsored by Yomiuri Shimbun. The sponsorship was later took by Asahi Shimbun.
I have quite a lot of games from the old (Yomiuri) Meijin tournament. Here's the search result on the event tag:
Meijin (Yomiuri): 412
Old Meijin: 101
But of course there are some inapproriately/ambigously labeled SGFs:
9th meijin 1970: 2
meijin (yomirui): 1
meijin (yomuri): 1
1st meijin 1962 league: 3
4th meijin title match: 2
9th meijin 1970: 2
5th meijin title match: 1
Those labels are found by searching for "mejin" with the date 1962-1975.
So the total is at least 525.
Update: The total is not 525 but 523. Try to spot a mistake on the above BOAB.
sgf2tex – 6/12/2006 1:40:17 PM
I'm currently adopting Minue622's tutorial on Haeng-ma to Indonesian. While going to add a pro game example which is lacking in the discussion about iron pillar, I thought it was going to be really painful entering the move coordinates one by one to LaTeX. Therefore I created sgf2tex:
Here's a sample output:
cleargoban
black{q16,q4,q10,p15,q6,r3,r2,m4,l4,n4,o5,n16,r16,k4,j5,h5,g6,r11,r12,p6,p10,p9,g7,g8,g9,g10}
white{d4,d16,o17,o4,q3,p3,k3,m3,l3,n3,g16,r17,q17,j4,h4,g5,r10,q11,q7,q9,s9,f6,f7,f8,f9}
begin{center}
showfullgoban
{comment}
end{center}
The annoying thing is that the SGF format uses a different coordinate system than what most Go players (including client) are used to. Conventionally, the rows are numbered, starting from the bottom, 1 to 19 while the columns are labeled, from left to right, a to t. The letter i is ommited to avoid the confusion between capital i (I) and lower case l (as is "lamp"). Compare I to l and you will see that it really looks similar. The SGF format labels the rows from the top and using letters from a to s. The columns are labeled from left to right using letters a to s.
pdflatex bug – 6/12/2006 1:28:19 PM
Creating Go diagrams using the igo.sty LaTeX package and then compiling the pdf using pdflatex produces wriggly lines:
This is probably a bug on the very old pdflatex that I use, so I tried the more orthodox and roundabout method.
The first is to create the dvi using latex, then create the ps using dvips, the finally creating the pdf using ps2pdf. To my dismay, wriggly lines still exist!
You can see that the lines near the left egde are wriggly.
What works well is converting the ps to pdf using GSView:
Indexing is slow – 6/11/2006 1:29:01 AM
Extracted the 40 thousands or so games from MGS's web site. Then added those games into Kombilo. The whole indexing process took almost 2 hours on my supposedly-powerful 1.9 GHz processor!
Anyway, I did a search on games involving a historical Meijin. Here are the Meijins (from first to last) and the number of games in my new database:
Honinbo Sansa – 0 (the number of games in my old database is 0)
Inoue Nakamura Doseki – 9 (0)
Yasui Sanchi – 126 (8)
Honinbo Dosaku – 61 (37)
Inoue Dosetsu Inseki – 15 (0)
Honinbo Dochi – 25 (0)
Honinbo Satsugen – 13 (0)
Honinbo Jowa – 64 (0)
Honinbo Shuei – 227 (0)
Honinbo Shusai – 499 (3)
The new database is clearly superb!!!
The number of games on my old database is only around 7 thousands. An interesting obersvation is that searching for sanrensei on both databases takes the same amount of time (1.8 seconds).
Mnemosyne 0.9.4 – 6/10/2006 9:31:34 PM
Mnemosyne is a flash card program. You give it a set of question and answers, and the program will schedule those questions for you. In other words, it manages the process of memorizing lots of items. It is a must for anyone learning a natural language (English, Japanese, Arabic, etc) where thousands of items (vocabulary) must be memorized.
I replaced my aging 0.9.2 with 0.9.4. Nothing spectacular, just bug fixes for things that don't affect me. For the upgrade process, I backed up the .mnemosyne folder (Windows Explorer won't let you create files/folder starting with a dot btw), exported my 0.9.2 Mnemosyne data to an XML file, uninstalled 0.9.2, installed 0.9.4, and finally exported the XML file. Everything went smooth.
Deletion of the contents of boab.txt – 6/10/2006 9:28:13 PM
On my hard disk, a BOAB is stored on the file boab.txt. I will then bring the text file when I surf the net and post the contents to my blog. I've decided that after I post it, I'll empty the contents of boab.txt on my harddisk.
It would be great if my offline BOAB is stored on a wiki. The full history of the file will then be available. I'll try to install MoinMoin Wiki later on Dapper (MoinMoin Wiki is the wiki engine used for Ubuntu's wiki; Wikipedia uses MediaWiki).
