blog

Rでピボットテーブルのようなものをつくるためのパッケージpivoteaを更新した． ホグワーツのデータを追加し，ちょっとバグを修正． https://cran.r-project.org/web/packages/pivotea/ https://github.com/matutosi/pivotea/

R Package Scholarというのがあるらしく，pivoteaがこれに登録されたとの電子メールが届いた． “pivotea is quite a useful package so we created some page tools for it!“だとさ． たぶん，いろんなところに送っているのだろうけど，褒められるのは嬉しい． https://scholar.rpkg.net/authordetails.php?author=Toshikazu+Matsumura https://github.com/matutosi/pivotea/

pivotea (pivot easy)の時間割データとして良いものがないか探していたら，ホグワーツ魔法魔術学校の時間割を見つけた． https://github.com/Arcfej/HogwartsTimetable/

Rでピボットテーブルのようなものをつくるためのパッケージpivoteaを作成した． 主な関数は，pivot()のみ． 詳細は以下を参考にして欲しい． https://cran.r-project.org/web/packages/pivotea/index.html https://github.com/matutosi/pivotea/ tidyなデータフレームをもとにして，列(row，縦)・行(col，横)・値(value，セルの中身)・分割(split)にそれぞれ配置したい列を文字列指定するだけで簡単にピボットテーブルのようなものが作れる． tidyr::pivot_wider(), tidyr::pivot_longer()でもピボットはできるが，同一セルに複数の値が入るときの処理が面倒くさい． 複数の値がある場合は，pivot()では縦に別の行として並べるところが，工夫点である． 同じコマに重複する科目があるときの時間割を作成するのに便利である(というか，それを目的に関数を作成した)． 以下のvignettesでは，このことが分かりにくいかもしれないと思ったので，時間割のデータを追加する予定． vignettes: https://cran.r-project.org/web/packages/pivotea/vignettes/pivoteasy.html

OpenAIのGPT-3に登録して，ちょっと遊んでみた． 文章生成やチャットをしてくれる． 内容的にはびっくりするぐらいよくできているが，具体性が少なく，どこかから取ってきた文章みたいで，内容自体には面白みに欠ける． GitHubのcoplilotもちょっと試してみた． これは，プログラムをAIがサポートするもので，コメントを書くだけでコードを提案してくれてすごく便利だ． ただ，誰かが書いたコードをなぞっているという感じで，全く新しいプログラムを想像しているわけではない． そのため，自分は具体的なコードを知らないけど，たぶん誰かが既に考えてるだろうというものを書く(勉強する)のに向いているとは思う． 一方，個別の事案や全く新しいものを作り出すのはやっぱり自分の頭が必要だ．

web茶まめという形態素解析ができるページがある． このページは非常に便利で，テキストを貼り付けるかファイルをアップロードすれば形態素解析の結果を得ることができる． ただし，APIが整備されておらず，このページを使うには手作業での作業が必要である． そこで，Rとrvestを使って作業を自動化することにした． 自動化のための関数が一応できた． 関数のコードはまだまだ改善の余地はあるだろうが，とりあえずは動く． 本来ならば関数の作成前に検索すべきだったが，完成作成後にweb茶まめをRで使うツールが既にあるかもしれないと思った． “chamame in r"で検索したところ，“Analyzed data of neko by chamame - R"となんともドンピシャな検索結果が出てきた． あまりにドンピシャ過ぎるのでちょっとびっくりしたが，恐る恐るリンクをクリックすると，自分のページだった． そりゃそうだな． ちなみに，このページの説明は手作業で取得したデータについてである． web茶まめ https://chamame.ninjal.ac.jp/index.html https://github.com/matutosi/moranajp/blob/develop/R/moranajp.R https://github.com/matutosi/moranajp/blob/develop/man/web_chamame.Rd

バグは恐ろしいものである． 恐ろしい理由は2つある． 1つ目は，バグだと知らずにプログラムを実行してしまう場合があるためである． その場合は，間違って得た結果を正しいものとして捉えてしまう． このような間違った結果をバグだと分かれば良いが，バグだと分からないと非常に恐ろしい． 2つ目は，なかなかバグの原因を見つけられないためだ． 原因を見つけにくい理由は，プログラマ(自分)の思い込みがある． ここにはバグが無いだろうと考えているところにバグが潜んでいることが多々ある． Rのパッケージへの機能の追加中にバグがあることが分かった． バグの原因究明に1日以上を費やしてようやく原因が判明した． バグの発生箇所は，なんとなく予想していた． ただ，なかなか最終的な箇所の特定ができずにいた． こんな箇所にバグはないだろうと思い込んでいた場所でバグが発生していた． 修正するべき箇所が判明して，コードの修正はほんの数分で完了した． バグを見つけるまでに約1日半ぐらい，修正に数分． 本当にバグは恐ろしい． ただし，バグにも良い副作用はある． バグを探している中でコードの改善を見つけて修正したり，新しい関数の使い方を覚えたり，関数の使い方を覚え直したりなどもできた．

テスト駆動開発というのは知っていたが，正直なところ面倒くさい感じがして，ちゃんと使っていなかった． ちょっとしたことだが，作ってみたいプログラムがあって，テスト駆動形で試してみた． 入力と出力が頭の中で整理されているのであれば(そうあるべきだが)，テストを先に作っておいてプログラムを書くのはすごく楽だとわかった．

生物多様性調査支援システムを大幅に見直し中． https://matutosi.github.io/biodiv/biodiv2.html せっかくPCやタブレットを使うのだから，よく出てくる種名は手入力せずとも選ぶだけにできるようにした． その他，地点ごとの出現種の表示(組成表みたいなもの)なども表示するようにした．

植生調査にも使える生物多様性調査支援システムを作成中であることを植生学会の大会で発表した． https://matutosi.github.io/biodiv/biodiv.html ただ，コードを見直すと，あまりにも汚い． 汚いというか，重複したものがたくさんあって，維持管理のときに困りそう． JavaScriptのプログラムを書くのが，ほぼ初めてのため，関数をどのぐらいのものにするかなど，あまり考えずに手当たり次第に作ったのが原因だ． 全体の形ができたので，設計し直しつつ，コードも整えようと思う．