>> そういうツールを入れる。

そうそう、初めてそういう作業に出くわしたらvectorやら窓の杜やらで検索して、
それっぽいフリーツールを何個か見つけてきてインストールして、
使い勝手のよさそうなのを選んで以後それを使えばいいよね。

で、ちょっと違う操作、たとえば一分毎に出力される
log.yyyymmddhhmmss フォーマットの大量のログファイルを
一日分毎にくっつけて log.yyyymmdd にするという操作が
必要になった時には、またそういうことをするツールを探せばいい。

でもそんなのすぐには見つからないし、作業毎に操作法の異なるツールを使うなんて面倒くさい。
できれば一つのツールが正規表をサポートするなどして、
ある程度の柔軟性を持ってくれた方が同じツールを使い回せて良いよね。

しかも似たような作業をまた今後もするのであれば、一連の作業をマクロで保存して、
2回目以降は自動化できればもっと良い。

でも日付やディレクトリは作業毎に違う可能性があるから、マクロは独自形式のバイナリじゃなくて、
テキストで記述されていて簡単にエディタで編集できなくちゃ嫌だよね。

おっと、そんな素晴らしいツールも出先の環境にインストールされていなかったら困るから、
できればどの環境にも標準で用意されていて欲しいし、上記のマクロ言語も業界標準化されてたらいいな。

もちろんそのツールだけでできることなんてせいぜい文字列操作程度で限られているのだけれど、
そのマクロ言語から他のプログラムを呼び出せるようにしておけばできることが飛躍的に増えるかも。

っていうか、そんな強力なツールなんだったらOSの基盤にも流用して、
ブート時やシャットダウン時の一連の初期化/終了作業なんかもそのマクロで記述すれば良いんでないか？

なんていう広範囲にファイル操作や文字列操作をするツールがあったとして、
マスターするまでは結構ややこしいけど、一度そのツールに習熟すれば様々な環境で様々な作業ができるし、
OSの基盤にもなっているわけだからマシン管理にも役に立つはず。

そう思わない？

まあ慣れだと思うけど、エクスプローラなりでctrlおしながらスクロールして選択、よっこらしょっとゴミ箱にドラッグするより

>for i in `seq 1776 3312`; do rm -f $i.txt; done

って打つほうがあっとう圧倒的に速いな、私は。

同じような例で、1.gif, 2gif, ..., 999.gif がある時、
001.gif, 002.gif, ... 999.gif のように0パディングでリネームしたい時って、GUIだとどうやってます？

連番GIFをくっつけてアニメGIFにする時とかでそういう事する
局面がよくあるんだけど、CUIじゃないと気が狂いそう。

×直行
○直交
です、ああダメダメだ、ごめんなさいごめんなさい。
人の文章に校正しろとかケチつける資格ないですね私は。
すいません。

ごめんなさい、誤解を招きそうな文章なんで注釈をいれます。
陸から見て東岸という意味で、海からみれば西岸です。
いわゆる西岸強化流というやつです。

コリオリ力は速度に直行する向きに働くので、
それ自体は仕事をしません。
つまり、直接的にはそれ自体はエネルギーを生みだし得ません。
コリオリ力って単に慣性を回転系から見たときに現れる擬似的な力ですからね。

ただ黒潮やメキシコ湾流のように、コリオリ力は風起因で海洋に注入されたのエネルギーを海洋の東岸に押し付けて東岸沿いに非常に強い海流を作るので、それでタービン回す等して電力に変えれば地球の回転でエネルギーを作ったと言えないこともないですが。
そのエネルギーの元は当然ながら風、すなわち大気の循環を作りだす太陽光の入射（とその地域的偏差）です。

>>キーのはしっこあたりを叩いていた人は、アイソレーションになると何もないところを叩くことになってしまいます。

さすがにそれはないだろ（どんだけ指細いんだ！）、
何もないところを叩くというのがジョークだとしても、
キーの端たたく癖のある人は、むしろアイソレーションキーの方が隣のキーの誤タッチが減って良いのではないか？

>Enterキーが青くなったのは ThinkPad A30/T30/X30/R30/s30からではないかと。
>時期的にレノボによる買収直前くらいに始まったもの。そんなに歴史はない。

そうなんだ、ちょうど私がThinkpad使い出したのがその時期だったからか。
WikipediaによるとIBMの最初のThinkpadが1992年, Lenovo買収が2004年末なので、あと4,5年すればIBM時代よりLenovo時代の方が長くなるんだね。

買収のニュースが出た時は私も含めみんな「ああThinkpadはもう終わった」って思っただろうけど、Lenovoは意外にというか、予想よりはるかにうまくやってると思う。
PCでまともにブランド価値を保って利益出す、って今のご時世神業に近いからな、まして中国の企業が。
品質・サービスは私的には十分許容範囲（というか今でもトップクラス)なんで、あとは中華的なバックドアが無いことだけを祈るよ。

同意。
ストロークとキーピッチが確保されていれば、アイソレーションタイプかどうかは打ちやすさの本質には関係ないですよね。
実際廉価機のX100eとかでも特に不自由は感じない、他メーカーの機種よりはるかにマシ。
で、アイソレーションの方が強度を保ちやすいのは事実だろうから、個人的には全機種アイソレーション化は（ピッチとストロークが劣化しないんであれば）むしろ歓迎。
ただ一部の人は7列じゃなくなったのはつらいんだろうね、私は7列右上のキーはまず使わないし、6列化でESCが近くなってかえってうれしいのだけど。

しかし、エンターキーの淡いブルーは残してほしかった、見た目的に。
赤ポッチとあのブルーがThinkpadのアイデンティティーなんだよ！

いやだから、私が
  >>そもそもDFTって言葉の意味もわかってないでしょ？
って書いたのは、翻訳のしょっぱなに
  >>DFT（短時間フーリエ変換）
なんて書いてるので、一般のDFTの話を勝手に短時間FTに限定しているから。
DFTといえば時系列データが対象で実用上窓関数が必須、と思い込んでいるようだが、あなたの従事する分野でそうだったとしても、一般を論じている今回の論文とは全く関係ないことですよね。
FFTには例えば3次元のカルテシアン座標上でポアソン方程式をスペクトル法で解く、なんていう窓関数とは無縁の用途もたくさんあるわけで。
だから、この人はDFTって言葉の意味すらわかってないんじゃないか、と思ったわけ。

>>窓関数の辺りのこと(データの最初と終わりが不連続になってピークが広がりを持つ)ことを言ってるのではないの？

この発言もちょっとおかしくて、窓関数が前提なことがそもそも間違いなのは先に指摘したとおりだけど、窓関数はサンプル区間の境界でデータの不連続をなくすために適用するもんなので、言っていることが意味不明。
窓関数を適用しないでぶった切る、つまり「矩形窓」を使うんだったら確かに不連続になってしまうけど、データの不連続が問題なんだったらそうならないような窓関数を適用するべきで、窓関数っていうのは普通はそういうものを指す。

で、窓関数があろうがなかろうが関係なく、この論文は変換後の波数空間でk個の非ゼロ値が連続しているなんて前提は一切ないのに、 あなたは、じゃなかったwakatonoo2氏は、著しい誤読の挙句、まるで意味がないかのような批評をしているので、誰か理解している人が指摘してあげないといけないでしょ？

あと、
>>離散ポイント間を矩形近似してることの誤差とか
こんなこと言い出したらこの論文の手法どころか、DFTそのものが無意味と言っているようなもんですよ。
FFTなんて速くてもまったく意味がない、って言ってるのと同じです。
もちろんそんなわけはなくて、離散化の誤差が問題になるのだったら問題にならないほど高いサンプリングレートをとる、あるいはレートが不十分ならそんな高周波は解析対象としない(できない)、です。

矩形近似ってのも意味わからんですが。
サンプルは点でとるので、FFTのアルゴリズム自体にそのサンプル間をどう補間するかという前提は全くないですよ。
強いて言えば正弦波の重ね合わせで補間する、ですかね。
少なくとも矩形補間ではないですね。

とまあ、乗りかかった舟なんで、私の知識で指摘できることは指摘してきます。