今年買ったもの(2019)

１年の振り返りを書きたいが何も思いつかない。とりあえず今年買ったものをだらだらと列挙してみることにした。

  • Asusのmini PC x2(i5, i7)
  • 液晶ディスプレイ（4枚）
  • 食洗器
  • ホットクック
  • ヘルシオ

商品名でひっかかると嫌なのでぼかしてるのがいくつか。

Asusのmini PC

6月頃になぜか変な価格の動きをしていた（異常に価格が下がっていた）ので，思い切って2台買った。i7が乗っているのを1台・i5が乗っているものを1台。

このPC・mini PCなんだけど，35WのCPUが乗っているというのが最大の素晴らしい点。普段使いでは完璧。m.2 SSDの換装が難しいことだけが欠点かな。ノートPCはCPUが非力なのかファンが回りまくるのが頭にきてたので。

このPC・Type Cの端子もついているも良い。手持ちのType C対応ディスプレイに対してType Cをつないで，ディスプレイ側にキーボードとマウスをつないでおくと，ノートPCとこのPCでディスプレイ・マウスを共用するのに便利。できればPC側からも映像信号をType-Cで送れるようになってくれると良いんだけどな。。。後Type-Cがディスプレイ側に2系統付くようになってくれる未来とか来たら最高なんたけどね。。。。

微妙な欠点としては，ディスプレイが4Kのマルチディスプレイになってからは悲鳴を上げることが多くなったことぐらい（これは私の使い方が悪い）。

DellのType C付23インチ（2枚)

とにかく普通に使う分には優秀の一言につきるディスプレイ。セールで2万前半で買ったような気がする。

デイジーチェーンでマルチディスプレイがいけるのもありがたい。

PC-Dell(sub)-Eizo(main)

と使うのが，普通の人にとっては良い構成だと思う。今年前半を乗り切れたのはひとえにこのディスプレイのおかげにつきる。ただし，4Kの世界を知ってしまった今，この構成ですらいらっときてしまう自分がいる。。。たまに23インチFHD使うとストレスが。。。

mini PCのところにも書いたけど，type-Cでつなで，ディスプレイ側にキーボードとマウスを置けるのは本当に大きい。Type-B - Type-Aでも同じことはできるが，Type-Aは指すのが面倒なので嫌なんですよ。とにかく。

4Kディスプレイ（27インチ1枚・32インチ1枚）

このブログでも取り上げた。

最初からケチらず32インチを買っておけば良かったの一言につきる。

マルチディスプレイの解像度は合わせておくにつきる。ほんと。

食洗器

一人暮らしのときにこれ買っておけばたぶん落ちこぼれずに済んだんだろうな・・・というぐらい素晴らしい機械。

自炊しなくてもあると良い。とにかく，コップと皿を贅沢に使えるというのは素晴らしい。

コップを洗うのが面倒で水をボトルからそのまま飲むとか，コップ洗うのが面倒でボトルから水を飲まないといけないけど2lボトルが重いので飲むまでの決断するまで時間がかかるとか，コップ洗いたくないから紅茶やコーヒー淹れるまでのふんぎりがつかずにだらたらするとか，して溶けた時間がこれまでの人生でどれだけあったことか。

皿洗いたくないからあっためずに容器のまま食べるとか，そういう食べ方してるとついつい食べ過ぎになりがちになるとかそういうのも防げるわけですよ。これ。

まあ，これ私がありえないレベルでダメ人間だから素晴らしい機械だと感じてる可能性もあるが。

ホットクック

今年の前半はこれで生命をつないだといっても過言ではない。

  • はかり・ 包丁・まな板がおけるスペース
  • 作ったものを展開するスペースや容器

がそろっていれば使いやすいマシンです。自炊するならあたりまえだろ？と言いたいがこれができれば苦労しない。ヘルシオを入れて以来，スペースが狭まった極度に使いにくくなった。

とりあえずポトフで適当に野菜炊いておいて野菜補給を一品分作っておく，という使い方で前半をしのいだ。シチューも良く作った。

最近は豚汁専用マシンと化している。

ヘルシオ

ホットクックよりさらに簡単なマシンでびびった。

最初はソフト蒸し目的で買ったが，そんな面倒なものは使うことはなかった・・・

取っ手なしフライパンを使う，というのがわかってから使えるようになったマシンともいえる。

肉を切って野菜をきって入れてまかせて焼きするという使い方。

ヘルシオもホットクックもこれで全部を賄うのはつらいが，とりあえずこれで何品か作っておけば野菜が補給できてかつ買ってくる総菜が減って良しという考えの自炊。

フォルダの結合のヘルパークエリを理解にかかることにした（１）

今年に入って，PowerQueryでフォルダ内部を結合しまくってる。

1つのシートの中に4つぐらいのフォルダを結合したものが別々に入ってくると，うっとおしくて仕方がない。特にこの補助クエリというやつのせいでクエリがかさんで仕方がない。

f:id:baruku07:20191215144700p:plain

フォルダを結合するときは相対パスを使う関係で，クエリ中の絶対パスを消しにかかるのだが，この書き換えをするときに元クエリだけでなく補助クエリまも書き換えが必要である（しかもそれに気付くのに相当かかった）。1個ならいいけど，4つあると2*4=8である。さらに，この補助クエリのせいでクエリのコピーで似た処理を複製することもままならない。

ということで，フォルダの結合のクエリをまじめに理解することにした。

まずヘルパークエリ以外のクエリはこんな感じである。

f:id:baruku07:20191215145346p:plain

ヘルパークエリが絡んでるのは囲んだ２か所である。キャプチャのソース全体。

let
    ソース = Folder.Files("（フォルダの絶対パスが入ってる）"),
    #"フィルター選択された非表示の File1" = Table.SelectRows(ソース, each [Attributes]?[Hidden]? <> true),
    カスタム関数の呼び出し1 = Table.AddColumn(#"フィルター選択された非表示の File1", "ファイルの変換", each ファイルの変換([Content])),
    #"名前が変更された列 1" = Table.RenameColumns(カスタム関数の呼び出し1, {"Name", "Source.Name"}),
    削除された他の列1 = Table.SelectColumns(#"名前が変更された列 1", {"Source.Name", "ファイルの変換"}),
    展開されたテーブル列1 = Table.ExpandTableColumn(削除された他の列1, "ファイルの変換", Table.ColumnNames(ファイルの変換(#"サンプル ファイル"))),
    変更された型 = Table.TransformColumnTypes(展開されたテーブル列1,{{"Source.Name", type text}, {"a", Int64.Type}, {"b", Int64.Type}, {"c", Int64.Type}, {"d", Int64.Type}, {"e", Int64.Type}, {"f", Int64.Type}, {"g", Int64.Type}, {"h", Int64.Type}})
in
    変更された型

結局は

  1. ファイルの変換([Content]))　
  2. #"サンプル ファイル"

の2つがヘルパークエリーに絡んでいることがわかった。

結論を先にまとめとくと，

  1. ファイルの変換([Content]))
    各行のテーブルの実態を得るために使っている。Table.AddColumnの各行にこの関数を適用して，ほしいテーブルの実際を各行に対してくっつけていくために使っている。
  2. #"サンプル ファイル"
    1.でくっつけたテーブルの実態をTable.ExpandTableColumnで展開するときに，引数として展開したい列を指定することが必要になる。それを得るために使っている。

ということがわかった。以下，１つずつ見ていく。

1. ファイルの変換

関数ファイルの変換の実態は次のようになっている。

let
    ソース = (パラメーター1) => let
        ソース = Excel.Workbook(パラメーター1, null, true),
        テーブル1_Table = ソース{[Item="テーブル1",Kind="Table"]}[Data]
    in
        テーブル1_Table
in
    ソース

1行目はExcel.Workbookにパラメーターを渡している。元のクエリの関数呼び出しを見ると，これはファイルのContentの行，すなわちファイルのバイナリを渡していることがわかる。

Folder.Files(絶対パス)で呼び出したテーブルの実態はこんな感じである。

f:id:baruku07:20191215150419p:plain

Excel.Workbookはバイナリを渡すと（ファイル名でない），その中身がExcelだった場合は，全部のシート・テーブル・範囲など使えそうなもの一覧で返してくれる関数である。レコードが返ると書いてあるがテーブルが返ってくるようである（見た目や後のアクセスの記法から推察して）

f:id:baruku07:20191215150938p:plain

PQを使い始めた最初，セルの中にバイナリの実態があるという考え方になじめずに戸惑ったのだがそういうものらしい。

で，そこから

ソース{[Item="テーブル1",Kind="Table"]}[Data]

として，得られたテーブルの中から指定したテーブル名と一致する（この場合はテーブル名「テーブル1」のものを引っ張ってきた）行を取り出して（{[Item="テーブル1",Kind="Table"]}），"[Data]"で実態を取り出すということになっている。

すなわちこの関数はExcelファイルの実態を与えて，指定したテーブルの中身を返す関数となっている。ただし，中身の指定は生の値で書かれていることに注意である。

この関数の呼ばれ方

ここで定義した関数はこんな感じで呼ばれている。

    カスタム関数の呼び出し1 = Table.AddColumn(#"フィルター選択された非表示の File1", "ファイルの変換", each ファイルの変換([Content])),

要は，Folder.Files()で読み込んだテーブルの各行に対して，ファイルの実態を渡してテーブルを返して，それを一列くっつけるということをやっているのである。関数適用後のテーブルを見ればこれはわかる。

f:id:baruku07:20191215151753p:plain

2.#"サンプル ファイル"

各ファイルに対して中身くっつければそれでほぼ目的は達成のはずである。なぜわざわざ特定のファイルを持ち出してるのかがわからない。

このファイルを呼ばれている部分を見てみる。

   展開されたテーブル列1 = Table.ExpandTableColumn(削除された他の列1, "ファイルの変換", Table.ColumnNames(ファイルの変換(#"サンプル ファイル"))),

Table.ExpandTableColumnなんで，どうやら中身を展開していることはわかる。その関数の引数に" Table.ColumnNames(ファイルの変換(#"サンプル ファイル")"がある，ということは自然に考えて展開する列名を取得していることがわかる。リファレンスをみても手動で展開してみてもそれで間違いなさそうである。

しかし，なんで全部の列名を展開するだけなのにわざわざ列名を取得する必要があるのか。よくわからないけど，これはそういうものらしい。全部を一気に展開するというのがみつからない（そんなのはないとまで書かれてるのもみかけた。ここは真偽はまだ確かめてない）。

プログラミング的思考について周囲を見てて思うこと（１）

（以下は全て何の根拠もない私見。言いたいことを正しさ関係なく自由に主張している。いちおう裏にソースとかないこともないけど面倒なので略。推敲もあまりしてない。文字にするとなんか正しいこと言わなければならないとか，勝手に信じ込む人がいたりする界隈なので最初に注意。）

小学校プログラミングはプログラミング的思考と言って入れは全てが許される感が出ている。とりあえず（１）にしてみただけで、（２）以降があるかはわからない。言いたいことをざっと書いてるのでツイートして並べてるのと論理構成のレベルは大差ない。

プログラミング的思考については、半径3m以内でおおまかに２つの問題が観察されていて

  1. プログラミング的思考以外に文科か言ってる重要ポイントを全部落としてる
  2. プログラミング的思考そのものを誤解している

というのがある。基本的にこれらを言葉で説得して解くのはだめだと思ってて、まずプログラミング体験して！って言うようにしてる。

だいたい、お上で議論するには言葉が必要で仕方がなく言葉になっている、それも本質を切り取っているか怪しい言葉なんだから、そんなものをはいそうですかと素人がいきなり信じて良いわけがない。体を生まれてから１回も動かしたことない人が（プログラミングは世の多くとここが違うのがポイント）スポーツの極意を言葉だけで議論してたら、まず体動かせって思うでしょ？

制御構造 = プログラミング的思考と思う人たち

プログラミング的思考に戻る。わけのわからない人たちは、順次・反復・分岐がプログラミング的思考だとして、あろうことか低学年からそういうのを計画的にやっていくことが大事だといってる人々がいる。（私の周りにはいないが）

しかし、指導要領・解説・手引きを何度読んでも、小学校で順次・反復・分岐の概念をきっちり習得させろとは読めない。

手引きを熟読した限りでは、今回小学校に求められているレベルは、何かのやりたいことをコンピュータにやらせるために、人間感覚でなくちょっとだけコンピュータ感覚に合わせて手順を明示化してみて、実際にコンピュータで動かしてみてうまくいったりうまくいかなかったりしたプロセスやプロセスから得る学びがメインだと読める。そして、余裕があればそこで得た知見を少しふりかえったり抽象化して日常のいろんなとこで意識してみましょうね、で十分である。その範囲内において、制御構造の学習（特にこれを言語化して抽象化して学習すること）は必ずしも必要とされていない。

もちろん、コンピュータに何かやらせたいという意図があったときに、それを実現したいとなったときに、制御構造必要だよね、となったときに制御構造が登場するのが自然。それも最初は制御構造の用語は必要ない。問題にあわせて「こういうときとこういうときでわけて考えないといけないよね」「くりかえさないとね」といえば十分。用語とか概念は、そういう体験が積み重なってきたときに、で、そういうの良く出てきてるよね、実は名前がついてて・・・と体験を抽象化する形で制御構造の話を出したければ出せば済むだけの話である。

多角形の例を考えてみればよい。ねらいを達成するためにはループは必須ではない。分岐も登場しない。

小学校でフローチャートを万能としてる人々はね・・・

だいたい、フローチャートはできの悪い疑似言語として使われていることもあるぐらいである。フローチャートが素晴らしいのであれば、世のプロクラミング言語は全て フローチャートに置き換えられているはずである。そうなっていないということは、フローチャートが微妙なものだからということだと思わない？そういう人たちは技術の解説でUMLが出てきた話なんかもしらない。

Scratchのほうがフローチャートよりわかりやすいと思わない？だいたいScratch使ってる人がみんなフローチャート使ってる？使ってないでしょ。Scratch使いこなしてもの作ってる人がプロクラミング的思考できてないと思う？

良く読めば、要はやりたいことを機械に落とし込むのがプログラミングで、そのために必要な思考がプログラミング的思考ということは手引きからちゃんと読める。それに照らし合わせると、Scratchでもの作ってる人たちは、フローチャートは描けないけどプロクラミング的思考はできてますよ。だって、その思考なかったらコンピュータ動いてくれいし。そんなScratchでちゃんと作れてる人たちに、変なペーパーテストと評価基準でプログラミング的思考ができてる人に、あなたはプログラミング的思考ができてません、とか評価するの（プログラミング的思考そのものは本来は評価する必要ないが、各教科の評価規準の作り方がへたくそで実質的にそうなった場合。）、おかしさにもほどがある。

だいたい、まともな人が書いてることにフローチャートの話はほとんどでてこない。だいたいフローチャートの話ばっかしてるのは、ろくにプログラミングもしたことはないけどプログラミング教育と言ってる人々である。しかし、素人がそんな著者の属性判断してそれがまともかどうか判断できるかわからないから、それを信じる人が増える。有害極まりない。

プログラミング的思考の説明に「論理的」という言葉を充てたことが個人的には大失敗だと思ってて、一般人はそれにひきずられてると思ってる。

順次・反復・分岐そのものにフォーカスを充てるのは、アルゴリズムにつなげるという主張もある。しかし、それは高校段階の話である。中・高の内容そのものが理解もできてない小学校の人々が考えた、自分なりのつながるなんて有害無益になる可能性がある。

もちろん、情報の科学手理解の教育の一部として、アルゴリズムのような情報科学入門みたいなことをやることはありえる。情報の科学的理解は立派に情報活用能力の一部である。でも、ITあやしい小学校教員がそんな教育やってる余裕あるの？というかコンピュータ関連、それよりもっと教育してきてほしいことあるし。文字操作とファイル操作をできずに中・高に送り出してる人たちどんなにいる？プログラミング的思考だけじゃなくて、それちゃんと小学校で終わらせとけって指導要領や指導要領解説で書かれてますが？そんなにお上のこと持ち出してがーがーいうなら、都合の良いとこだけ読むなと言いたい。

液晶追加で買った（32インチ）

27インチの4Kのマルチディスプレイの相手がFull HDの問題は、さすかに不便すぎるので32インチ4Kを買い足すことを決断した。EIZOの27インチ4Kを追加したかったのだが、なぜが同じディスプレイが前回購入時と比較して1.5万も値上がりしてる。頭にきたので32インチを買った。

32インチを買っての感想は、まあ、１画面で何かを集中して読む分（要はWebブラウズ）には少し縦が長すぎるかなと。椅子とディスプレイの高さをちゃんと調整してあげないと首が少し上向きになるので痛くなるのである（アジャストの効きやすい自宅になるアーロンならまた話は違うんだろうけど）。ただ、Excel方眼系の作業はものすごくはかどった。想定した通り、だいたいアプリケーションを3枚並べて使おうと思えば使える感じになった（125%表示）。

27インチで125%常用はしんどいが、subで125%にしておく分には問題ない。倍率は揃えておいたほうがいろいろと楽なのでそうした。

メイン32・サブ27で高さの差はでるが、両方同解像度なのでアプリケーションの高さを調整してから反対側ディスプレイに移動するという手間がなくなったのでだいぶん楽。ギャップがないほうが良いのは良いが。

32も27も奥行きあまり変わらないからというレビューが出てたが、さすがにフレームの太さは違った。これはマルチディスプレイするときに注意。最近のフルフラット感覚でふちなし感覚でマルチできると思ってたけど、32はそうはいかない。

32を2枚にしたいけど、そうすると机中央部分が継ぎ目になる問題が発生しそう。たぶんアームを入れて作業ごとに位置をうまくかえながらやるのがベストなんだろうけど。ただ、アームは一度導入に失敗してるので・・・，

液晶全とっかえする財力が欲しい・・・

消費税アップ前に、駆け込みでEIZOの27インチ4Kを１枚ついに買った。

1回使い始めると、4K以外の環境に戻れなくなる。

2560x1440のときは、画質が少し荒く感じてて、まあ何となく見にくいから便利とも言い難いなとか感じてたわけです。ところが4Kになると全くそういうのがなくなる。

ここのとこ、作業の求められるレベルが上がってきた割には、縦解像度1080で作業してきてた。しかし、久々に縦あるので作業すると、やっぱ縦1080はないなという気分。

27インチ4Kに不満はないが、問題は、デュアルでの相手ディスプレイ。4K側を150%にしている関係で、下の領域でしか２枚目のディスプレイへアプリが移動できないこと。となるともう１枚買いたくて仕方がない。

さらに実家で24インチの縦1200で作業してても27インチ4Kが欲しくなる中毒ぶり。

32インチ4K買ってもそうなるのかな・・・

データの取得でフォルダを読み込むときに相対パスを使おうとしてはまる

Rあたりだと，複数のExcelファイルを一括で読み込まして結合するぐらいなんてことはない。パッケージがある。ところがExcelだとそれが面倒。

Excelしか使わない職場でそんなん必要なのか？なんだけど，同一ファイルの同一シートに複数の人間に入力させると見通しが悪くなるので，複数ファイルに分割させて入力させたいという要望がある。

自分一人で作業するなら，CSVで入力をしておいてPowerShellを開いて

*.csv > filename

としてファイルをくっつけて，後からソートでヘッダを消すという強引なことをやるのだが，他人様が絡むとそうはいかない。あと，CSVはExcelで使ってると警告がいちいちうるさいのでできればそれを黙らせたいのでExcelてやりたい。

最近，世間にはPowerQueryという便利なものがあるらしいということを知った。これを使ってみたところ，やりたかったことができて問題はなくなった。ただ，まだ他人様に渡せない。この機能，フォルダを指定すると絶対パスで指定されるため，他のマシンに持っていくと使えないのである。自分が使う分には，ソースの変更でフォルダを再指定してやれば済むのだが，他人様にそれをお願いするわけにはいかない。

ということで，相対パスで使えないかと調べたものの，私の日本語能力では探しきれなかった。

結局，ぐぐってでてきたのは，なんかわけのわからない横文字で色々書かれているものだった。

https://techcommunity.microsoft.com/t5/Excel/Power-Query-Source-from-Relative-Paths/td-p/206150

これを参考に動かしたところ動いたのて記録を残しておく。（気が向けばスクリーンショットとか貼ってわかりやすくする）

書かれてた解決法

まず，これを適当なセルに打ち込んで，

=LEFT(CELL("filename",$A$1),FIND("[",CELL("filename",$A$1),1)-1)

それにFilePathという名前を打ち込んでから，

    FilePath = Excel.CurrentWorkbook(){[Name="FilePath"]}[Content]{0}[Column1],

としろと書いてある。

要は

  1. 読み込ませたい絶対パスをどっかのセルに作る
  2. その部分をテーブルにして名前をつける
  3. PowerQueryで読み込む

とのことらしい。まあ，そうだろうと貼り付けれる性格ならそれで問題ないのだが？本当か？とはまった。以下は適当に調べて理解したことを書きつらねたもの。

適当な解説

1.絶対パスの作成

適当なセルに

=Cell("filename",$A$1)

とすると，ファイルのフルパスが生成される。ただし，これだとファイル名まで入ってしまうので除去してしまう必要がある。この関数，ファイル名が"[]"で囲まれて帰ってくるらしい。それを利用して，

FIND ("[",CELL("filename",$A$1),1)

と[の位置を探して，Left関数で（"["の1文字手前までで切り出すので式に-1が入ってる）パスの部分だけを切り出している。

このフォーラムでのシチュエーションは同一のフォルダにあるブックを読み込むというシチュエーションなのでこれで仕事は終わり。

私の場合は，その直下に作った集約用のディレクトリのファイルを全部読み込みたいという要望なので，ここで文字列を&で結合するなどして，読みたいパスを生成すれば良いということがわかった。

2.その部分をテーブルにして名前をつける

テーブルでないものはPowerQueryから読み込めないので，テーブルに変換する。何もしなければ，列名が日本語で「列1」とついてくる。あとは，テーブル名をわかりやすくするためにFilePathと変更している。

3. PowerQueryで読み込む

Letの後に

    FilePath = Excel.CurrentWorkbook(){[Name="FilePath"]}[Content]{0}[列1],

として読み込む。後は，クエリの絶対パスがあるとこをFiePathに帰ればOK。

マイクロソフト様のありがたい仕様書を読んでみたが・・・

Excel.CurrentWorkbookまではわかる

Excel.CurrentWorkbookまでは元のリファレンスを追って，手元で動かしてみればなんとなくわかる。

Excel.CurrnetWorkbookはテーブル名とコンテンツのペアのテーブルを返すらしい。

大量のかっこの規則性がまったくわかんない

https://docs.microsoft.com/en-us/powerquery-m/operators:embed

によるとはRecord lookup operatorで

Access the fields of a record by name.

で，名前でアクセスできることになってて，{}はList indexer operatorで，

{} Access an item in a list by its zero-based numeric index.

で，indexでアクセスできることになっているらしい。

Excel.CurrentWorkbookはテーブルを返す。そっから先がわからない。{}はindexによるアクセスなので，で該当するインデックスをひっぱってきてると考えるのが自然。ただ，ExcelCurrentWorkbookの直後の部分がひっかかる。{}の中にを書いたとき，がインデックスを返すと明確に書かれてる部分が自分には見つけられない。

まあ，仮に{[Name="FilePath"]}の部分を受け入れるとすると，

  1. ExcelCurrentWorkbookでテーブルの一覧を返し
  2. {[Name="FilePath"]}でテーブル名FilePathのNameとContentのペアになったリストが帰し
  3. 2.から[Content]をを抜き出して（だから名前アクセス）
  4. 3.から0行目を抜き出して（{}だからindexのアクセス）
  5. 4.から列1という名前の列のものを抜き出す（[]だから名前アクセス）

と思われるのだが。今のとここういう適当な理解。

某実験本にあったお下品なコード（１）

最近、とある分野の実験統計の本が出てたので購入した（タイトルでの検索を避けるためにあいまいな書き方をしてる）。

まあ、この分野は例のごとくデファクトがStataだからStataで書かれてるのは仕方がない。しかし、この本の後半はStataのパッケージを使うのではなくStataの行列言語で手でいろいろやろうということになってる。

で、Stataが悪いのか著者の腕が悪いのか、こんなコードがでてくる

gen y0 = y == 0
gen y1 = y == 5
...
gen y16 = y == 80

下品極まりない。でもStataのリファレンスは読みたくないし、となるとこういうコードを生成することになる。こういうとき、さっとirbとかpryを立ち上げて

(0..16).each{|i| print "y#{i} = y == #{5*i} \n"}

と書いて実行して、doファイルに貼り付けて、ああめんどくさいことが終わったとやるのって普通？プログラマとしてはだめなんだろうけど。

この本のStataのコード見てるとそんなのばっか。なので、

  • なんかの言語のテンプレートエンジン使ってdoファイル作る
  • doファイル生成とdoファイル実行をmakefileとか書いて実行させる

みたいな感じにしないと、普通はやってられないと思うんだけどな。

もちろん、Stataのちゃんとした文法調べれば良いんだけど、Stataのスキルって転用不可能だから、そこにリソース割くのは得策じゃないしね。

このやり方を洗練させる方法を調査しても良いが、今の私はStataが手に入るご身分ではないのでできなんですよね。。。ということで、全部RとPythonでやっつける以外の選択肢はないんだけど。

なお、こういう下品なコードにいらついている人が私の周囲にはいなかったのも悲しかったな。。。。なお、このシリーズ、たぶんゆるゆると続いていくのでとりあえず（１）にしてる。