ブログ

ツッコミを入れたくなった。
でも入れなかった。
だって。
しょうもないことだったし。
言うだけ無駄な気がしてならなかったし。
だから黙ってた。

『本で見たところ、矢印が双方向に向いていない。どうやら片方の向きにしか
矢印を書くことができないという決まりがあるようだ』
・・・いや。違う。
確かに矢印の向きについて説明してあるページでは単方向にしか書かれてない。
でも、次のページを捲った瞬間に、その決まりがブチ破れてる。
例として示されてる図で思いっきり双方向にも逆方向にも向いてしまってる。
これ、どうなの（汗）
と、思ったけど。
しょうもないことなので。
黙ってた。
だって。

そもそも日本の企業の大半がユースケースなんか書かないらしいじゃない（誤爆）

確かにちゃんとした企画をする場合にはいるかもしれない。
でも、必要に迫られるのは銀行だとかそういう本当にシステムが
重視されてる場合であって、ゲーム会社なんか特にそういうことをしないらしい。
だから。
ある程度やり方が分かればそれでいいじゃない。
便利だよね、でいいじゃない。
キリキリするのは、銀行のシステム考えるような状況になったときでいいじゃない。
自己流でいいじゃない。
そう。

結構こういう作業にズッポリハマっちゃうオレなんか、
キリキリし出したら止まらないわよ（おいおい）


で。あと。
今日は。
学会発表エントリー用文章書いてた。
なんでこんなことしてるんだろな自分・・・とか思いつつ。
で。
そもそもどういう文章を書けばいいのか理解してなかったオレは、
大いに的外れな文章を書いてしまったわけで。
そう。学会発表なんだからきっちりしなきゃいけない。
つまり論文。
それをこんな・・・宣伝口調で・・・何してんの自分...orz
しっかり教授に注意されました。
言われて気付く。

「あ、そうか」

・・・気付くの遅いぞテメェ。

で。書き直し。
曖昧な表現はしない。きっちり説明。
で、句読点は,こう.
まぁ・・・ぽくなったかな。
再提出。ＯＫ。通った。
もーボケてるわー自分。

エントリーはとりあえず乗り切った。
問題は展示用ポスターの作成。
どういうポスターを作るのか、あれやこれやと教授から聞き出す。
そうしていると、教授が・・・

「○○さんだから絶対できるよね」

〜・・・ッ！！（ワキワキ）

こういう期待を即裏切りたくなる自分はいろいろ終わってる（爆）
こんなときは・・・『やれ、と命令されてる』と解釈しなきゃやってられない。
自我を持って物事に取り組むぐらいなら自殺してるっての。
それが許されないから無理矢理生きてるわけで。
『当たり前』が許すなら速攻死んでやるっての。
がうがう。
・・・はぁ。作業しよ。

大学にて。
印刷できない。
おかしい。
ネットにも繋がりにくいが。
繋がったところで印刷できない。
データはちゃんとサーバまで飛んでるっぽい。
が、プリンタ無反応。
何回もデータを飛ばしてみたが、結果は同じ。
場所変えるか・・・いや、サーバがダメなら一緒か。

うんうん唸っていると。
印刷室に出入りする人影。
入って出てきては
「あれぇ〜・・・？」
とか
「ダメかぁ・・・」
とか。
ありゃあ、同じ現象に見舞われてますね。絶対。
こりゃダメだ。仕方ない。
サポートセンターの人呼んでこよう。

「すみません。印刷できないんですけど」
「あ、わかりました見に行きます」
再び印刷室へ。
そこには先ほどの人影が。
よく見れば・・・同じく次の講義を取っている同学科のお方でした。
つまり、同じ課題を印刷しようとして、こうなってるわけで。
そりゃあ急ぎですな。お互い様。
で、サポセンの方がプリンタを見て・・・
「う〜ん。データ来てませんねぇ・・・え〜っと・・・学籍番号は？」
「あ、はい」
そう言ってパソコンに書いてある学籍番号を確認し、
「・・・ちょっと調べてみるね」
行ってしまった。

「どうしよう。教授に事情説明するかなぁ・・・」
「そうやなぁ。この状況じゃなぁ・・・」
「確か教授、今下の階で講義してたよな」
「え、そうなん？」
「呼び止めて説明するか」
「そうした方がいいかなぁ・・・」
「僕昨日から印刷しようとしててんけど・・・」

「昨日はネット自体が落ちてたからなぁ・・・」

「う〜わ・・・まぢで？」
「そのときに教授おったし、分かってくれるよなぁ」
「それなら分かってくれるやろ」
「まああの教授、なんだかんだで優しいから」
「講義の時厳しすぎやねん・・・」
「講義じゃないときに話しかけたらそうでもないで？」
「そうなんかぁ・・・」
と、グダグダ会話。

しばらくして、サポセンの方が帰ってきた。
「溜まってたデータ全部消したんで、もう一回データ飛ばしてもらえます？」
「おかしいデータが来てたんで、データは来てるみたいなんですが・・・」
だとか。
ということで再チャレンジ。
しかし。
結果は同じ。
「だめですねぇ・・・」

で。
結局どうしたかというと。
「USBに印刷したいデータ入れてもらえます？」

「プリンタに直接線を繋いで印刷します」

・・・！！！
ご、ごめんなさいそんなことまでさせてしまって・・・
しかし甘える（爆）
印刷。
できた。
ホッチキスで止めて・・・間に合った。提出。
もう一人もなんとか提出。
めでたしめでたし。


・・・


・・・あれ？

根本の問題（サーバに溜まってばっかりで印刷できない）解決してなくない？


・・・頑張れサポセンの人（汗）

グロ注意。



いくら自分がどういう評価をしようが外道は外道。

なんだか。
やる気が、でない。
いや、いつものことだけど。

こう、何かしなきゃいけないときって、ホント。
違う方向に力注ぎたくなるよね。
ラクガキとか読書とか・・・爆睡とか。
だめだねぇ・・・むむむ。
でもさ。
そうやって違う方向に力注いだ後なら、やる気になったり・・・いや、ないか。
なんかそっちに走り出すと止まらないんだよねこれが・・・

で、だよ。
やっぱりオレは根性悪い絵が好きらしい。
というのも。
たまたま見かけた全然知らない人の絵を見て、
「あ、これやべ」とか思ってしまったわけだけど。
おかんに見せたら「う〜わ根性悪そッ！！！」って言われて。
オレの絵を見たときでもおかんには
「また根性悪い絵描いて・・・」って言われてるけど。
そうか。やっぱりオレは根性悪い絵が好きなのか・・・と思った。

で。問題は。

根性悪い絵が好きなオレは根性悪いのかなんなのか。
・・・多分悪いんだろうね（汗）

姐になにやら質問されたので、マジメに考える。

内容は、LZ78というデータ圧縮アルゴリズムの実装方法について。
まぁ、ようはlzh形式のデータをどうやって作るかって話。
軽く調べてみたところ、LZ77とかいう方法もあるらしく、
そっちはスライド窓なんていう方法を使ってるらしいが、
LZ78はそれを改良したアルゴリズムなんだとか。
ふ〜ん。

本題。
とりあえず、辞書なるものを作るようで。
圧縮したいデータをはじめから見ていって、辞書になかったら登録。
簡単に言えばそうなんだけども・・・
登録の仕方が変わってて、どう実装するのやら、と。


たとえば。

abcababc・・・とでも行きましょうか。
とりあえず最初の文字、aを登録。0a。

残りはbcababc。
次の文字、bはまだ辞書に登録してないから、登録。0a,0b。

残りはcababc。
更に次の文字、cも登録してないから登録。0a,0b,0c。

残りはababc。
問題はここから。
aは登録してある。登録してあるのは1番目。
じゃあ次のbを足したabだったら？
これは登録してない。だから登録する。
どうやって？
『辞書に登録してある1番目の文字列+b』ということで、1b。
結果的には0a,0b,0c,1b。

残りはabc。
aは１番目に登録してある。abも4番目に登録してある。
でもabcは登録してない。だから登録。
『辞書に登録してある4番目の文字列+c』ということで、4cでOK。
0a,0b,0c,1b,4c。

圧縮完了。

abcababcという８文字は0a0b0c1b4cという１０文字に・・・
って増えとるやん！！？
いやいや、たまたまっすよ。
同じような文字列がだらだら続けば断然短くなるでしょうよ。
例えばaaaaaaaaaaaaaaa、とか？
a,aa,aaa,aaaa,aaaaa・・・0a1a2a3a4a？
１５文字が１０文字に。2/3ですか。そうですか。
なんか無駄に一色だけの画像がなんで軽いのか垣間見た気がするね。
とりあえず、ようはこんなかんじ。


これを実装しようとするとどうすればいい？
我思うに。
１文字目の時点で辞書に登録されていない場合、
次の文字と合わせた２文字は辞書の中には絶対ない。
つまり。
aが登録されてないのに、abが登録されてるはずがない。
と、いうことは。
１文字目が見つけられなかった時点で、その文字は登録すればいい。
１文字目を見つけたのなら、２文字目も引っ付けて探す。
探す文字は１文字目の辞書番号がついたもの。
つまり。
aが辞書で2番目に登録されていたのなら、
2がついたものを辞書から探せばいい。2aとか2bとか2cとか。
なければ登録。あったら次を探す。
これの繰り返し。


・・・まてよ。
これ、ひょっとして木構造にできたりするのか？



む。できなくはない。
ただ、これだと辞書の番号を別で管理しなきゃならん気がする。
まあ登録するデータの属性を文字データとインデックスの２つにすりゃいいか。
・・・いやまて。
これでエンコードはできたとしてもデコードが超不便・・・だよな。
ぬぬぬ？
デコードしていくと辞書データを蓄積しつつ解凍するわけで・・・
蓄積していく際には後で出てくる変な文字列は関係ない。
後から出てくる文字列は新しく蓄積されるべきデータなんだし。

・・・いやいやいやちょっとまて！！
そういう問題じゃないぞこれは！！

そもそも木構造として考えた理由は「検索しやすく」であって、
デコード時には検索なんて必要ないじゃん！
必要なのは何番目のデータを使うかってだけ。
「２個目のデータ使ってね」的な。「２ページ目を見てね」的な。
そう。そうだ。
辞書は引いた後なんだ。引く作業はやった後なんだ。
引くのは大変だけど、引いた後はしおりを挟めばいいだけ。
次に見るときは時間をかけて探す必要はない。
数字はしおり。そういうことですね。


ということで。
姐にそれっぽいことを言ってみた。
すると。
どうやら最終的にしなきゃいけない作業は、
辞書に登録してある内容を順番に表示する、だそうだ。
つまり。

木構造のままじゃアウトですが何か（爆）

う〜ん・・・
エンコードしながら別の配列にデータをブッコんでいけば？（投げやり）