BruteForce入金消込開発記

完全に回想録です。思い出としてこれからも書き足していこうと思います。(だって、要望も批評もナイから開発が止まってるんで、新しいネタがありませんのデス...T_T)


【ダウンロード数】
2004.12.28 通算16(Ver. 1.11.00) 2004.02.25 通算61(Ver. 1.01.00) 2003.06.24 通算69 (Ver. 1.00.00)
2005.01.26 通算93(増分77) 2004.03.25 通算98(増分37) 2003.10.29 通算270(増分201)
2005.02.23 通算163(増分70) 2004.04.29 通算126(増分28) 2003.11.26 通算314(増分44)
2005.03.30 通算203(増分40) 2004.05.26 通算154(増分28) 2003.12.24 通算340(増分26)
2005.04.26 通算229(増分26) 2004.06.30 通算194(増分40) 2004.01.28 通算386(増分46)
2005.05.24 通算245(増分16) 2004.07.28 通算217(増分23) 2004.02.13 通算407(増分21、終息)
2005.06.29 通算268(増分23) 2004.08.25 通算242(増分25)
2004.09.29 通算272(増分30)
2004.10.27 通算295(増分23)
2004.11.24 通算321(増分26)
2004.12.20 終息

2005.5.19 バグフィックス (Ver. 1.11.01)
●実害はないと思いますが
ちょっとしたバグを発見しました。消込検索後の(複数候補による)組合せ検索において、諸入金伝票に対する各候補数が、たまたま一致してしまうと前処理の対象外となってしまいます。まぁ、前処理というのは飽くまで処理スピードを向上させるためのものであり、なくても処理結果には影響がないハズですが...
●バグフィックス
●くどいようですが
とりあえず実害はないハズなので、敢えて公開版の差し替えは行いません。つか、今回ひさびさにこの組合せ検索を使ってみたら、えらく使いづらいな〜(^^)。せめて、検索結果で該当するものが皆無だったときは、候補欄は消さずに元に戻すぐらいはした方がいいかな。
2004.12.29 DLレポート
●あれ?
DLレポート、チョット遅れ気味で今日やっと届いたんだけど、イキナリVer. 1.11.00版の報告になってた。いつもだったら改版前の最終総数も知らされてたのに... ま、どうせそんな大した数でもないだろけどサ(T_T)。
2004.12.21 マイナーアップデート版 (Ver. 1.11.00)
●バグフィックス ●変更 ●拡張 ●あ...
ver. 1.10.00のときにゆってた、「配布前提のソフトに対する作りこみ」の部分、まぁ〜ったく考慮されてません... ゴメンナサイ(_ _)。今回も、飽くまでマイナーアップデートにとどまってイマス...
●イマイチかも...
ところで、コレでようやく印刷対応版をお届けできた訳ですが、自分的にはこの印刷結果、まだまだ満足いくものにはなっていません。というのも印刷されたものを見ると、消込の番号(セルの行番号を使っています)が直感的になんのことかわかりづらいと思ってます。ただ... これまた自分的には、前にも申し上げたとおり、印刷することはホトンドないため、使いづらいことに対する無頓着さがどうしてもあるのです(ま、いっかって...^^;;)。
●ご意見求む!
一応こんな風な方がいいのかなぁと思われるポイントとしては以下のようなものが思いつきます。 ...いかがでしょう?度合いの差こそあれ、いずれも手を抜きたい作者の怠慢で実装していないモノです(^^;)。印刷したものを見るのは(消込作業者でなく)全く別のヒトと考えると、今のままでは問題なのかなぁという気だけはしている、という状態です。実際に使ってみてどうかという、生の声がゼヒいただきたいのですが...(_ _)
2004.06.30
●仕様です(^^)ゞ
弥生販売のデータを取り込む際、「カンマ区切り」で、かつ「年号が和暦」のデータしかサポートしていません。ボチボチ拡張していこうかとは思いますが... 例によって作者は不便を感じないし、要望があるわけでなし...(いじいじ
2004.04.30
●収束ぅ〜
ボチボチ新ネタを... と言いたいところだが、このヒトツキ、まーったくナンモいじってませーん。
2004.03.25
●収束に向けて
断っとくが「終息」ではないので念のため(^^)。うーむ、1.10.00を公開すべきか否か。
2004.02.25 DLレポート
●えっ?!
今日ベクターからダウンロード数の連絡があった。どう解釈したものかチトとまどうのだが、この『BF消込』の方は、『元帳印刷』にあった既存ユーザによると思われるダウンロード数の跳ね上がりがナイ。うーむ。
●もしかして
『BF消込』って、ダウンロードはされても使われてないってことか?だからアップグレードの必要なんかないと?ガーン。しくしく(T_T)。これまた発信側に立って初めてわかる、無反応に対する絶望感... お願いだからナンか感想クダサイよ〜。
2004.02.13 印刷機能強化版(Ver. 1.10.00)作成
●ソフト配布って...
昨日、リンクに追加したサイト『Excelでお仕事!』であるが、そもそものところはナニかの役に立つこともあるかな、程度の気持ちだった。しかし、Excelベースのソフトを配布するにあたっての留意点のホンのとっかかりを少し読んでみただけでもイキナリ頬を張られたような衝撃である。
●印刷なんて考慮してませんでした
曰く「ページ設定は必ず行う。印刷目的でないことが明確なら別ですが、配布を受けた人が印刷しないとは限りません」。ガビーン(^^)。拙作の『BF入金消込』は、印刷を目的とはしていない。清書でなく処理が目的のシステムだからだ。事実ワタシはこのシートから印刷をかけたことなど一度もない。
●とは言うものの
そこが「配布」前提のソフトと、そうでないソフトの違いであろう。確かにワタシは印刷の必要はないと思う。しかしそれはワタシが弥生販売と組み合わせて使っているからだ。弥生と何の関係もなく、純粋にコレのみで消込帳票として使うヒトがいるかもしれない。となれば、シートの印刷機能は必要ではないか。
●でも公開はしないモンね(^^)
他に使うヒトがいるかもしれないから、と言っておきながらアレだが(^^)、しばらく公開するツモリはない。何より、今日ようやくベクターからVer.1.01.00の更新登録のしらせがあったばかりなのだ。自分が使う訳ワケでもない、ヒトから要望があったワケでもない、そんなモノをあわてて公開する必要もなかろう(全く反響もナニもないモノを更新するのってやる気が萎えるよね...)。
●習作
今回のバージョンアップは、「配布前提のソフト」開発のための習作的位置づけである。印刷以外にも満たすべき要件はまだまだあるはずだ。 その辺をじっくり検討・改変を加え、それが落ち着いた段階で公開を考えたい。
●拡張
2004.02.06 マイナーアップデート版(Ver. 1.01.00)公開
●バグフィックス ●変更 ●さぁ、これでこそ
先日、『弥生元帳印刷』に比べると『BF入金消込』の出足が落ちてることについて言及したが、考えてみれば一応はアップデートがかかった直後のハナシなワケで、新規ユーザーが増えていっているコトにはならない。今度こそ同じ条件である。サテ、どちらに軍配が?(←そういう問題じゃない気もするが^^;)
2004.01.21
●あ、ウソ書いてる(^^)
こっそりマニュアル改訂(^^;;)
2003.6.某日
●公開!(その2)
うーむ、先の公開から一ヶ月経過したが、未だに反応がない(T_T)。ここはいっちょ、もう一箇所公開場所を確保しよう... というワケで、ベクターに登録。
2003.5.某日
●公開!
Excel Q&Aのお膝元、Excel Factoryさんのフリーソフトコーナーに登録していただく。
2002.12.某日
●5bit配列に苦戦
C言語と違い、VBAはbit演算がイマイチ弱い(と感じる)。特にビットシフト演算子がないのがなぁ。左シフトは2をかけて、右シフトは2で割る。ふぅ、やれやれ、まずは読出しモジュールができたぞ。get_nth(n,bin)とやると、バイナリデータbinの5bit配列でのn番目の要素を返す関数である。ここまではまぁ、順調だったのだが...
●書込みがうまくいかん〜(T_T)

put_nth(i,n,bin)とやると、n番目の要素にi (0<i<32)をセットするというもの。コレでデータをセットして、get_nthで読み出してみるんだけど、入れたデータと違うのが出てきたりする。ナゼじゃ〜。
●用途から機能を検討しよう
この5bit配列の用途は、言うまでもなく売上伝票の組合せを表す数列の格納である。詳細は省くが、組合せを作り出す時、前からある組合せ集合に新しい伝票番号を追加するようにしている(例えば集合{1, 2, 1-2}に要素3を加えて{1, 2, 1-2, 3, 1-3, 2-3, 1-2-3}となる)。つまり、いきなりn番目の要素にデータをセットすることはありえず、空の配列にまず1コのデータを1番目にセット、次のデータ1コを2番目にセット...という具合。
●何も普通の配列と同じ使い方ができなくても
というワケで書き込みモジュールは、データiを一番最後に追加する add_one(i,bin) のみとした。もちろんちゃんと動いた。
●よぉっしゃ!
いつもだったらスワップが起こるタイミングだが、オンメモリで動いている。当然検索時間も短〜い(^^)/
2002.11.某日
●お知恵拝借
困ったときのSalon頼み(^^)。重複チェックのアルゴリズムについて、質問を投げてみた。正直「掲示板の趣旨が違う」と怒られるんじゃないかと戦々恐々である。
●ソレだッ!
やっぱヒトの意見は貴重だ。たとえ直接の答えでなくとも、新しい考え方のヒントを得られることが多い。キーワードは「二分検索」。コレは、既に既出チェックの際に使って上々の成果をあげているが、同じコトを重複チェックでもやりゃいいやん!
●結果は
チェックサム以上の劇的スピードアップ!比較量(バイト数)を減らすより、比較ステップ数を減らす方が効果的、という結論(当然か...)。しかも、完璧に重複ないし。やったー(^^)/
(このやりとりはSalon No.22173にて)
●でも比較量も少ないにコシタコトない
チェックサムほどでないにしても、現状32バイトほどもあるデータを短くできれば、スピードが速くなることは実証ずみ。なんか手はないものか... ん!考えてみたら、今3ケタの10進数をマンマ文字列3バイトでやってんだよなぁ... もしVBAで符号なしbyte型整数なんてのがあれば、0〜255まで1バイトで表現できる!データ量が3分の1になるぞぉ〜。
●255もいらんワ
仮に255も検索対象伝票があったら、今の感じじゃソレこそ何日かかることやら。127でも多い。63か31か... うーむ、ほとんど31以下で済むと思うんだけど、時々40ぐらいあるからなぁ... ま、とりあえず31にして、5bit配列モジュールを作ろう!
2002.10.某日
●対象伝票削減
これまで全伝票の組合せを検索してきたけど、考えてみりゃ入金額より高額の売上伝票は始めから対象外やんけ。お、トーゼンながら速くなった。ハッピー(^^)v
●行き詰まり
ワリと全体的にまとまってきた感じ。一応消込検索できるようになったし... ンが!やっぱ伝票数が増えると指数関数的に検索時間が増大する。検索そのものよりも、メモリのスワップに時間がかかってるようだ。三日三晩走らせ続けてやっと止まったと思ったら「メモリが不足しています」「システムが不安定になりました」(T_T)。いくらムチャな使い方だからってハングっていいワケじゃないぞ〜。このタコOSがッ!(怒)
●検索の内幕
前述の通り、組合せパターンは金額計をキーとして二分木に登録している。大雑把にこのときのアルゴリズムは以下の通り。
  1. 二分木検索により、ある組合せの金額計が既出かどうかをチェックする。
  2. 初めての金額計だったら、木のノードとして然るべき位置に追加。
  3. 既出だったら、その組合せが既に登録されている組合せと重複していないかチェックする。
  4. 重複していなければ、その金額計の組合せとして登録。重複なら捨てる(何もしない)。
●スリム化できるのは
手順3の、重複のチェックがクセモノである。組合せ情報は、伝票セルの行番号3桁をそのまま並べた文字列として登録している。伝票数は最大でも12ほどだったが、つまり、組合せのデータは1件につき3x12=36バイト使用しているワケだ。これが個々の金額計につき、(重複をなくしても)ヘタをすると数百も存在するのだ。1コ新しい組合せが出るたびに、数百も検索していては時間がかかってシャーない。ナンかいい手はないものか。
●チェックサム
お〜、懐かしい響き(^^)。昔16進ダンプを手入力するときにはズイブンお世話になってたものだ。余談はさておき、組合せパターンの重複チェックに、チェックサムを使ったらどうだろうか。組合せの伝票セル番号の合計を一緒に登録しておき、チェックの際は本体でなく合計同士のみチェックする。合計は当然整数型で精々4バイト。32バイトの比較から4バイトの比較になるんだから、単純計算で8倍の高速化になるハズだ。
●結果は
8倍どころじゃないくらいのスピードアップに感じる!しかぁし、あいにくというか当然というか、重複が残ってしまっている(例えば合計で10になる整数の組合せは何通りもある。チェックサムではそれらを認識できない)。それにチェックサムの分、確実にメモリは余計にかかっているし。sigh...
●「珠玉のプログラミング」購入
たまたま雑誌の書評欄を見ていたら紹介されていた本。コンピュータアルゴリズム関係の本らしい。作者がどうやって効率化を図り、スピードアップ、メモリ節約を実践したかが書かれているという。参考になりそうだ。
2002.9.某日
●既出チェックの高速化
これでも某大学情報工学科を出たyonetch。サーチとかソートのコーディングについては講義でベンキョーした(ハズ)。「そうそう、昔やったぞ。二分検索とかクイックソートとか... アレ?でもあんときゃPascalのポインタ使って線形リスト構造とか二分木構造とかインプリしたんだったよな。VBAでできるんかいな?」
●Q&A Salonデビュー
自分なりに調べてみるものの、できるともできないとも判断のつかないyonetch。意を決してSalonで聞いてみることにする。「あの〜、数百万コのデータ処理でぇ(中略)ポインタってVBAで出来るんですかぁ?」
●キツい洗礼
「数百万なんてExcelにはムリです。データベースを使いましょう」。うがっ(T_T)!だよなー、普通はそう思うよなー。元SEとしての自分も同感だし(^^;)。しかぁし、趣味のプログラマとしての自分は、数百万を数万に減らすために「ポインタの使い方」を質問してるんだけどなー。質問に答えてほしいなー。
●ポインタはポインタでも
データ自体は普通に配列に格納し、そのインデックスを格納した別の配列を用意することでリストだろうが二分木だろうがインプリ可能なことを教えてもらう。ガーン!目からウロコが落ちまくり(^^)。そうか〜、PascalやC言語とは違うけど、これも一種のポインタだなー。
●ちょお速ッ&軽ッ!
早速コーディング。このスレッドの中で、既出チェックに関する画期的な方法について示唆を受ける(己が無知やっただけじゃ^^)。あわせてコーディングすると、メモリ量もスピードもダンチ!(このやりとりは、Q&A Salon No.19280から始まるスレッドを参照) 
2002.8.某日
●いかーん!(^^)
気が付けばヒトツキ近くVBAのコードに触っていない。VBA習得の題材として選んだ入金消込だったのに、アルゴリズムに悩んでVBA習得自体が疎かになってしまった。本末転倒とはこのことじゃ〜。
●チカラ技でいこう!
何のために機械にやらすんだ。単純な繰り返し、これこそ機械の専門分野ではないか。というわけで、とにかく総当りで検索する方法でインプリメントしてみることにする(重そ〜^^;)。
●セルが足りん!
データの載ったシートの他にワーク用のシートを用意して、組合せのパターンをワーク用シートに並べてみた。とたんにセル不足に陥る。折り返しの位置計算とかもメンドウ。必然的に配列に格納することにする。
●全組合せを重複なく
まずは全組合せを作るための多重ループ。すぐにメモリが足りなくった(T_T)。あ、全組合せったって、この場合順序は関係ないんだからA,BとB,AやA,B,CとA,C,Bは重複だな。これでメモリが節約できる。
●既出かどうかチェックして組合せを登録
組合せた伝票の金額計が同じで重複しない組合せを、順次配列に格納。はじめの内はいいけど、要素数が増えるとむちゃくちゃ時間がかかる。メモリを節約してもこれじゃあ使い物にならん(T_T)。つまんなくなって(^^;)、またまたしばらくほったらかす...
2002.7.某日
●ようやくVBAに慣れてきた...
これでようやくノミやカンナがちょっと使えるようになっただけ。これでどれだけ立派なウチが建てられるか?
●CSVファイルからデータ取り込み完成
なんといっても、まずは弥生販売のデータを取り込まにゃハナシにならん。CSVファイルの開き方、それらのデータを集計してシートに配置する方法、そのアタリを習得。
●組合せ検索のアルゴリズム
さて、データが用意できたところで、いよいよ検索モジュールの製作に入る... といったものの、サッパリ見当もつかない。単純に考えたら、入金額に対して売上額を適当に組合せて比較して... ってのを延々繰り返すってことになるが、なんかスマートじゃない。そんなチカラ技じゃない方法があるはずだ...
●展開がないとアキるよね(^^;)
で、1,2週間ヒマを見つけては考えるが、何も浮かばない。そうこうしているうちに、やる気というか興味がだんだん失せてしまい、しばらくほったらかしになる。
2002.6.某日
●Excel VBA事始
さーて、VBAにチャレンジするぞ。ナンか目的がないとモノにならんから、前から苦労してた入金消込を題材にしてみよう(弥生販売の入金消込ってナンデこんなタコなんや!)。サテ、VBAのコードって、ドコにどう書きゃいいのン?(先が思いやられる...T_T)
●Excel Q&A Salonとの出会い
どう考えても先達の知恵をお借りせねばラチがアカン(T_T)。ぜったいインターネット上にそういうサイトがあるハズだ。さて... というワケでいくつかあった中で、投稿者のレベルが高く、デザインや機能がスッキリして好感がもてたのがExcel Q&A Salon。しばらく、ROMに徹してVBAコーディングの基礎を学ぶ。