妖精現実

[ 新着記事 | 数学・プログラミング | 天文・暦
| シリア語・Unicode・詩 | ジョーク | 漫画・アニメ
| 字幕 | 哲学・ファンタジー | 全記事 | チラ裏 ]

チラ裏

2021-06-22　【続報】ProtonMail の v3 onion に疑義　プライバシー生活への移行は「いいかげんな気持ちで」

前回（2021年6月20日）、ProtonMail が先週 v3 onion に対応したことをお伝えしたが、その対応には、まだ不備があるかもしれない。

具体的なことは後日に譲るとして、「がっかり・ショック」というよりは「やっぱりね」と感じた。

前回も書いたように、ProtonMail については、過信せず「いいかげんな気持ちで」使うくらいでちょうどいいと思われる。本気で end-to-end のメール送受信をしたいなら、当たり前だが、余計な中間者を通さず、互いにローカルで鍵ペアを作って、直接、公開鍵を交換すればいい。そうすれば、どんないいかげんな回線経由でも、数学的にセキュアと信じられている通信（数学的なことなので誰かを信用する必要がない＝ただしこれは「予想」であり「証明」はされていない）ができるし、現在の Thunderbird では OpenPGP が最初から付属していて、一般ユーザーでも GUI を使って簡単に操作できる。

大企業などがユーザーの一挙一動を追跡する傾向が増している現在のインターネット。プライバシーに注意を払うのは、もちろん良いこと。とはいえ、一般ユーザーから見ると、自分で鍵交換することは面倒と感じるかもしれない。

そういう意味では、一般ユーザーでも手軽に使える Tor Browser（ブラウザ）、DuckDuckGo（検索エンジン）、ProtonMail（ウェブメール）などを少しずつ生活に取り入れてみるのは、最初の一歩としてお勧めできる（お金はかからないし、嫌ならいつでもやめればいい）。仲間に言わせれば「DDG がまだ続いていることは奇跡」。ちなみに Startpage という手もあるが、あれは羊の皮をかぶった Google にすぎない（Ixquick の時代には独自だったが…）。Google を使いたいのなら、Startpage より SearX の方がいくらかましかも…。だけど G を使うということは、基本的に「G が見せたいページに誘導される」「あなた個人が満足すると推定されるページ（あなた個人の趣味・思想に合ったページ）に誘導される」ということで、それだけだと、プライバシーの問題は別にしても、物事を高所から多角的に見ることができなくなる心配もある。

Proton を完全に匿名で使いたい場合、「アカウントを作るときにメアドを入れなければいけない」というジレンマが生じるかもしれない（プロバイダのメアドなどを入力したら、全然匿名にならないよね）。回避手順は次の通り。ウェブメールでは一貫して Tor Browser を使い、まず Cockmail のメールアカウントを作って、Proton にサインアップするとき Cockmail で確認メールを受信。この方法だと、個人情報を何も渡さず、一度も生IPを見せずにウェブメールを使える。もちろん直接接続する Tor の入り口ノードには生IPがばれるし、「注文のご確認。お届け先住所・お名前」みたいなメールを受信したら、まあ、あんまり意味ないかな…。

だからやっぱり最初のうちは「プロトンには生IPを見られてもいいや、グーグルよりはましでしょ」くらいのいいかげんな割り切りが大切なのかもしれない。何ならブラウザを分けて、クリアネットの普通用ウェブメールと、オニオン経由の匿名ウェブメールと、2個アカウントを作ってもいいかも。「身元を隠すのは怪しい行為」という洗脳から自らを解き放ち、「余計な個人情報をばらまかない方がいいに決まっている」という基本に立ち返ろう。

そもそもユーザーが何もしなくても、メーラーが自動的・透過的に OpenPGP を使うようになってもいいようなものだが…。どうやらリアルワールドとかいう場所には、「メールを中間で読めないと困る人々」というのがいるらしく、有形無形の…あれ、誰か来た

2021-06-20　ProtonMail: v3 onionにようやく対応

ProtonMail は必ずしも信用できない。具体的に、ずっと v2 onion のままなのが、懸念の一つだった。けれど先週、いつの間にか（2021年6月14日ごろ）、ひっそり v3 に対応していた。

「v2 廃止」の警告が出るようになっても、この会社は「v3 対応の準備中だが、具体的なスケジュールは未定」のようなことを言っていた。爆発的に大きくなってしまい、対応が後手後手なのかもしれない。あるいは商売っ気が過剰になって、もう腐りかけているのかもしれない。

自社のVPNサービスを販売する都合上、「プライバシー的には無料でもっといいものがある」ことを前面に出しにくいのだろう。「友達と一度鍵を交換すれば、どんな回線を使っても簡単に end-to-end で暗号化できますよ。OpenPGP は Thunderbird のデフォの機能です」「ところで ProtonMail を使っても、通信相手が G ならメールは全部読まれてますよ」なんてことを言ったら、一般の客は逃げてしまう…。多くの人は「暗号化しているから安全」という誤解に基づきつつ「信用してお任せする」という選択をする。

「誰も信用できず回線は盗聴され放題だとしても、正しい手順を踏めば、ほぼ安全でセキュアな通信ができる」ということは、計算量（一方通行関数）の問題で、直観的に分かりにくい。

同人関係の人はよく「自分が死んだら、恥ずかしいファイルを見られないように、誰かにHDを消してもらいたい」というようなことを言う。そのように「誰かに頼ること」が既に脆弱性。そこまで見られたくないのなら、最初から（今からでも）デリーケートなファイルは全部ローカルの仮想ドライブに移動させ、毎回パスワードを入力すればいい。仮想ドライブの実体を巨大でも怪しまれないタイプのファイルにしておけば、家族・知人の目を欺くくらいはできるだろうし、仮想ドライブとばれても、本人が死んでパスワードが不明なら、誰にもロードできないから問題ない（笑）。

ProtonMail も「暗号学的には気休め程度（プライベートキーをサーバー側に置くのは、本質的には、暗号化してないのと同じ）。でもグーグルと違い、勝手にメールを読まれて広告を入れられる心配はない」くらいの、いいかげんな気持ちで使えばいい。「個人情報を何も渡さず、登録から利用まで全てTor経由の匿名でできるサービス」は、10年くらい前と比べると、結構増えている。ネットが自由になってきたというより、逆に「一挙一動を監視するサービスが当たり前になってしまった」ことへの反動として、それをうっとうしく感じるユーザーの間で「お金を払ってでも、プラバシーを尊重してくれるサービスに移行したい」という需要が増えているのだろう。

2021-06-18　MKVToolnix（続報）　libｍagic から乗り換えへ

libmagic がフォントのMIME型をおかしくするのは、MKVToolnix史上、少なくとも3度目。最初はまだ font/ が公式に定義されていない時期。独自に font/ を使い、互換性問題が生じた。2回目は2019年ごろ。Mac上で MKV を作ったら、application/font-sfnt というマニアックな型（技術的には間違いではない）を書き込まれ、再び互換性問題。この時点で libmagic に疑いが生じたが、MKVToolnix の作者は「このライブラリは事実標準」と擁護。そして今回（2021年）。主要プレーヤーが標準準拠して1年半たったから、準備そろそろOK？とレガシー対応を廃止したとたん、また libmagic が TTF を font/sfnt という変な型にしつつ（技術的には間違いではない）、OTF をレガシーにするというちぐはぐな挙動。さらに TTC が font/ttf というのは、訳が分からない。

libmagic の返すフォント型がミッション・クリティカルになる場面がほとんどないので、報告されず、放置されているのだろう。字幕制作者は過去のいきさつに懲りて、--attachment-mime-type を明示的に書くようになっているため、MKV でも問題が表面化しにくい。

MKVToolnix の作者もとうとう「これはおかしい」と考え、libｍagic 自体を使わないように変更した。実用上、とりあえず賢明な選択かもしれない。けれど、変更の思わぬ副作用として、フォントとは別の添付ファイル（カバーアートなど）で、分かりにくい互換性問題が生じてくる可能性がある。しばらく添付ファイルのMIME型をよく確認した方がいい。

さいわい主要な動画プレーヤーは、font/sfnt のようなレアな型にも対応しているし、「MIMEを認識できない場合は拡張子をチェックする」という安全策を施した実装もある。自動更新で何も考えずに MKVToolnix 58 にしてしまっても、再生サイドの実害は限定的だろう。

ただ MPC-HC の最後の公式バージョン（clsid2 が引き継ぐ前）を使い続けているユーザーは、内蔵フィルター使用の場合、今後、埋め込みフォントがロードされないケースが増えてくるかもしれない。

2021-06-15　【動画作成注意報】MKVToolnix 58 添付フォント型に不具合　更新するなら慎重に

2021年6月13日にリリースされた MKVToolnix v58.0.0 の GUI では、フォント・アタッチメントのMIME型の自動認識が変更された。背景については「MKV埋め込み字幕用フォントのMIME問題」を参照。

注意点:

1. 今回の変更によって、古めのプレーヤーはフォントを正しくロードできなくなり、字幕表示が乱れる。おおむね2019年10月以前のバージョンが影響を受ける（MPC-BE 1.5.4以前、MPC-HC 1.8.8以前、LAV Filters 0.74.1以前）。不特定多数の人（古めのプレーヤーを使っているかもしれない）にファイルを公開する場合、要注意。

2. 技術的問題。標準準拠のための変更なのに、MKVToolnix v58 がデフォで使う MIME-type は標準準拠になっていない。#3137 として開発者にフィードバック済み。

暫定的推奨:

状況がクリアになるまで v58以降への更新をせず、しばらく様子見が吉。

MKVToolnix v58 の GUI を使うと、非標準なファイルが作成され、禍根を残す可能性がある。どうしても58 の GUI を使いたい人は、Preferences | GUI | General Options のUse legacy MIME types for font attachments にチェックを入れると、後方互換になる。状況を把握できていて、自分でコントロールできるなら、更新しても問題ない。

MIMEタイプが標準準拠になること自体は、原則的には良いこと。けれど MKVToolNix 58 は、標準準拠にしたつもりで中途半端になってしまっている。これを開発者が「magicライブラリの仕様」と主張するのか、それとも、標準仕様とずれていることを認めて修正するのか…。

追記: 開発者もこれが不具合であることを認めた。修正されるまで、バージョン57以前を使い続けることをお勧めする。

短期的には、標準準拠に実用上のメリットは何もなく、リスクだけがある（互換性が失われて一部のプレーヤーで字幕が正しく表示されない）。かなりの人々が、当面、明示的にレガシー（後方互換）を使い続けるのではないか。コマンドラインから使えば、MIMEタイプは好きに設定できるし、GUIからでも上述の「レガシーモード」のオプションがある。けれど手動設定が必要。一般ユーザーがデフォのまま操作すると、変なファイルが作成されてしまう可能性がある。一般ユーザー視点では、v57 以前を使い続けるのが、手っ取り早い。

2021-06-07　物理的な不良セクターがあるSSDのクローン

「SSDは使ってないと壊れやすい」は、これで痛い目に遭った…という失敗談。

電源がオフだと、物理的にも無防備なのだろうか。何かの天罰で宇宙線でも当たったのかもしれない。

壊れたものは仕方ない。とりあえずセクター・バイ・セクターのクローンを作って、不具合のあるSSDと入れ替えておいた。

2021-06-06　【注意】SSDは使ってないと壊れやすい　用がなくても週に1度は電源を

「SSDは、アクセスが速く、回転部分がないので壊れにくい。従来のハードディスクより優れた新技術…」という一般的イメージを持たれている。

一方、SSDには、特有の弱点があることも知られている。そのうち「通電していないとデータが壊れる確率が上がる」という事実は、用途によっては重大な問題点だろう。

IBMサポートの資料「Flash Data Retention」によると:

「一般的なイメージとは裏腹に、フラッシュメモリー上の情報は、恒久的に保存されるものではありません。これは NAND Flash 技術の特性であり、データを長期間保存するためには、電源を入れて使わなければなりません。FlashSystem 900 は40℃以下の環境において、最大90日間まで電源オフの状態にして大丈夫です。電源オフの状態が7日間を超える場合、システムは自動的にリフレッシュ動作を行います」

言い換えると、そのような自動リフレッシュがない一般の環境では、電源オフが1週間を超えると、データ損失・破壊のリスクの増大が無視できないレベルになる。もちろん確率は低いが、イメージ的に「日常的に使っていれば、一定期間ごとに100万分の1の確率で起きる悪いイベントが、1万分の1の確率で起きるようになる（100倍のリスク）」みたいな感じかも…。この特性から、当然ながら、SSDは「週ごと、月ごとの定期バックアップ先のメディア」としては不向き。そのような用途では、古い技術であるハードディスクの方がはるかに信頼性が高い。「SSDの方が値段が高いから信頼性が高い」と誤解してはならない（衝撃に対する信頼性は高いかもしれないが…）。

確率上の話として、SSDの場合、毎日じゃんじゃん使う方が、保存されているデータは「論理的」に壊れにくい。もちろんデバイスの「物理的」な消耗は早くなるが、形ある物がやがて壊れるのは仕方のないこと。消耗品と割り切って、必要なら定期的にバックアップやクローンをするしかないだろう。「余計な消耗を防ぐため、なるべく使わないようにしよう」と考え、長期電源オフにすると、むしろ壊れるリスクが増えると思われる。

参考リンク: Will SSD lose data if left unpowered for extended period? : DataHoarder (reddit)

2021-05-29　動画注意報: madVRの色スケールがTV（16-235）になってしまう

現象　Windows 用の MPC-HC や MPC-BE において、ビデオレンダラーとして madVR を選び、PCスケール（0-255）で出力させる設定をしている場合、全画面表示では望む色レベルが得られるものの、ウィンドウ表示にすると、スケールがTV（16-235）になってしまうことがある。真っ白が薄灰色になり、真っ黒が真っ暗にならず、赤やピンク系が微妙にずれた色調になる（少し濃く・暗く見える）。

説明　この問題は、ハードウェアアクセラレータ（GPU）が有効になっていて、DXVA Native が使われる場合に、GPU回りの相性によって発生するらしい。「字幕のレンダリングに XySubFilter を使う場合に起きる」という報告もある。上流において、何らかの方法で明示的にTV→PCの伸張を行っている場合には、原則として発生しないようである。

サンプル画像

madVR Full-screened と右下の EVR-CP Windowed は、RGB各成分・誤差±1程度の同じPCスケールで表示されています（この色調を得たい）。右上の madVR Windowed は、微妙にですが、目で見てはっきり分かるくらい色が違う。赤っぽいおだんごの部分で比較すると、他と比べて、G成分が 0x10 = 16階調も暗過ぎる。

回避方法　幾つかの選択肢がある。

• madVR をやめて Enhanced Video Renderer (custom presenter)（略称: EVR-CP）を使う
• madVR を使いたい場合、ハードウェアアクセラレータの設定を DXVA2 (copy-back) に変更する（テストとして、ハードウェアアクセラレータ自体を無効にしてもいい）
• せっぱ詰まった場合、奥の手として、上流に TV-PC 変換をする Shader を挟んで、強制的にレベルを広げる方法もある。しかし全画面表示では既にPCスケールになっている状態において、Shader で一律に伸張すると、全画面表示では2重伸張になって白飛び・黒つぶれが起きる懸念があるので、確認が必要

テスト方法　設定上、madVR では出力が PC levels (0-255) になっていること、EVR-CP では Output range が 0-255 になっていることを最初に確認。x264あたりの適当な動画を再生して、一時停止。できれば真っ黒 RGB(0,0,0) のピクセルがあるフレームがいい（カラーバーでもいい）。ウィンドウ表示と全画面表示のそれぞれで、フレームをPNG形式でキャプチャー。同じことを madVR と EVR-CP の2種類のレンダラーについて実行（レンダラーを変えたら動画を開き直す）。キャプチャー画像のどれも色が同じなら、問題は発生していない。もし上述の現象が起きている場合、madVR のウィンドウ表示のみ、他と色が微妙に変わり、(0,0,0) になるはずの真っ黒ピクセルは (16,16,16) くらいになる。

参考情報　madVR 開発者からのコメントは次の通り。「個人的意見ですが、copy-back に変更して済ませてはどうでしょうか。いずれにせよ DXVA Native は厄介で扱いにくい代物。GPU次第で違う結果になり、もしかすると GPUドライバーの（バージョンの）違いで、結果が変わってしまう可能性さえあります。だから Intel GPU で起きることは、多分、私自身が Nvidia や AMD の GPU で起きることとは恐らく違うのです」。madVR側で対応する気はなさそう…。手元では Nvidia の GPU で、現象を再現させることができた。

2021-05-15　log (1 + i) とか　～その2～

前回の続き。

4.　そもそも、log a^b = b log a というのは、どういうことだろうか？

log a というのは e^□ = a を満たす □ のこと。例えば a の値が e³ だとすると:
　　log a = log e³ = 3　（なぜなら e³ = a）
…当たり前。

log A というのは e^□ = A を満たす □ のこと。今度は A の値が a^b だとしてみる。ただし a = e³, b = 2 とする。
　　A = a^b = (e³)² = (e³) × (e³)
　　= (e × e × e) × (e × e × e) = e⁶
　　だから log A = log e⁶ = 6

上記のように、実数の範囲では指数法則 (e³)² = e^3×2 が成り立つので:
　　log (e³)² = 「eを何乗すると (e³)² になるか」
　　= 「eを何乗すると e³ になるか？」の答えの2倍
　　= (log e³) × 2 = 2 log e³

同様に考えると、一般に log a^b = b log a が成り立つのは、当たり前に思える。実数の範囲では…ね。

5.　ところが複素数の範囲では、そうとも言い切れない。a = 1 + i, b = 2, 3, 4, … とすると、前回チラッと観察したことだが…
　　log a² = log (1 + i)² = 2 log (1 + i) = 2 log a
　　log a³ = log (1 + i)³ = 3 log (1 + i) = 3 log a
　　log a⁴ = log (1 + i)⁴ = 4 log (1 + i) = 4 log a
までは順調に進むのだが、
　　log a⁵ = log (1 + i)⁵ ≠ 5 log (1 + i) = 5 log a
…という衝撃の事実（？）が待っている。これは「主値」というものを考える場合に起きる現象。

とりあえず (1 + i)² などの部分を直接展開して、何が起きるか見てみましょう。
　　(1 + i)² = 1² + 2 × 1 × i + i² = 1 + 2i + (−1) = 2i
　　だから　log (1 + i)² = log 2i

log w = log |w| + i arg w という性質を思い出そう。上記の場合 w = 2i で、複素平面を考えれば、その絶対値（原点からの距離）が 2 であること、偏角の主値が 90° つまり π/2 であることは容易に分かるので:
　　log (1 + i)² = log 2i = log 2 + πi/2

前回見たように log (1 + i) = (log 2)/2 + πi/4 （☆）なので
　　log (1 + i)² = 2 log (1 + i)
がちゃ～んと成り立つ。ここまでは楽勝。

同じことを「3乗」の場合について考えると:
　　(1 + i)³ = 1³ + 3 × 1² × i + 3 × 1 × i² + i³ = 1 + 3i − 3 − i = −2 + 2i
　　だから　log (1 + i)³ = log (−2 + 2i)
この −2 + 2i は、絶対値が √8、偏角の主値が 3π/4 なので:
　　log (1 + i)³ = log (−2 + 2i) = log √8 + 3πi/4
ここで √8 = 2^3/2 に留意すると、先ほど見たように、実数の範囲では log a^b = b log a なので
　　log √8 = log 2^3/2 = (3/2) log 2 = (3 log 2)/2
　　従って　log (1 + i)³ = log √8 + 3πi/4 = (3 log 2)/2 + 3πi/4
これは（☆）の3倍なので
　　log (1 + i)³ = 3 log (1 + i)
も、ちゃんと成り立つ。

最後に (1 + i)² = 2i は上記で計算済みなので、その両辺を自乗して (1 + i)⁴ = (2i)² = −4。だから
　　log (1 + i)⁴ = log (−4) = log 4 + πi = 2 log 2 + πi
これも（☆）のちょうど4倍なので
　　log (1 + i)⁴ = 4 log (1 + i)
も、また正しい。

2乗・3乗・4乗まではOKなのに、何で5乗になると、同様のシンプルな関係が成り立たないのか？　大方予想がつくだろうが arg w の部分で「偏角の主値」を選ぶというところに問題が潜んでいる。（続く）

2021-05-08　log (1 + i) とか　複素関数って値の変数名がwで草

実数の範囲では log a^b = b log a のような計算が成り立つが、複素数の範囲ではどうだろうか。順を追って、あれこれ考えてみたい。

1.　z を複素数とする。e^z つまり exp z の値を w とするとき、
　　A = log w = log |w| + i arg w
という複素数は、
　　exp A = w
という関係を満たすが、A = z とは限らない。一般に、A は z を含めて無限個の値を取ることができるのだった。そのうち特定の一つ（具体的には arg w として、偏角の主値 Arg w を選んだ場合）が、log w の主値とされる。主値以外の log w の値は、主値と 2πi の整数倍の差を持つ。

簡単に言えば…

• log w の値は一つに決まってなくて、虚部に 2π の整数倍を足したり引いたりしても構いませんよ～
• だから log w には無限個の値が考えられるけど、どれか一つだけは、虚部が −π より大きく π 以下の範囲になるので、その一つを主値としますよ～

ということだった。

2.　例えば 1 + i は、絶対値 √2、偏角の主値 π/4 なので、log (1 + i) の主値は:
　　A = log (1 + i) = log √2 + i(π/4)
という特定の複素数。主値以外も含めて言うと、k を任意の整数として:
　　log (1 + i) = log √2 + i(π/4) + 2πik
　　= ½ log 2 + ¼(8k + 1)πi

ここで log √2 = log 2^½ = ½ log 2 という関係を使った（実数の範囲では、このような計算が成り立つ）。

k = 0 のときが主値に当たる:
　　A = log (1 + i) = ½ log 2 + (π/4)i = 0.346… + (0.785…)i

この複素数 A は exp A = 1 + i を満たす。

主値以外の例として、例えば k = 3 とでもすると:
　　B = log (1 + i) = ½ log 2 + (25π/4)i = 0.346… + (19.634…)i

この複素数 B も exp B = 1 + i を満たす。

＜検算＞　複素数 z の実部を x、虚部を y とすると、e^z つまり exp z は、こうなる:
　　exp z = exp x cis y
ここで cis y = cos y + i sin y は偏角を表す単位ベクトル（偏角そのものは y）。従って:
　　exp A = [exp (log √2)] cis (π/4)
　　= √2 cis (π/4)　　［なぜなら exp (log X) = X］
　　= √2 [cos (π/4) + i sin (π/4)]
　　= √2 (√2 / 2 + i √2 / 2) = 1 + i
exp B では上記の cis (π/4) が cis (25π/4) に置き換わるが、両者は等しいので最終結果は同じ。□

log (1 + i) 自体は、そんなに難しくなかった。上で見たように、その主値は:
　　A = log (1 + i) = (1/2) log 2 + (π/4)i = 0.346… + (0.785…)i

3.　では log (1 + i)² はどうなるだろうか？　実数の世界の感覚としては、主値として
　　log (1 + i)² = 2 log (1 + i) = 2A
　　= log 2 + (π/2)i = 0.693… + (1.570…)i
とやりたくなるが、この変形は正しい？

答えはイエス。虚部が −π より大きく π 以下の範囲にあるのだから、上記は主値の条件を満たしている。一方、それとほとんど同じに見える次の計算は、正しい主値を与えてくれない:
　　log (1 + i)⁵ = 5 log (1 + i) = 5A
　　= (5/2) log 2 + (5π/4)i = 1.732… + (3.926…)i

何がいけないの？　まず最後の虚部 3.926… は π = 3.141… を超えている。主値の条件を満たしていないので、これが主値ということはあり得ない！

もう少し具体的に言うと、A の虚部は π/4 なのだから、その4倍を超えると、上記の「主値の範囲」をはみ出してしまう。結果として、
　　log (1 + i)² = 2 log (1 + i)
は正しいのに、
　　log (1 + i)⁵ = 5 log (1 + i)
は正しくない。表面的には同様の変形に見えるのにね…

本をただせば「主値」というコンセプトが、人工的というか、すっきりしない。虚部が −π より大きく π 以下の範囲という約束は、不自然ではないが、必然的でもない…。虚部が 0 以上で 2π 未満の範囲としたっていいわけで…。要は幅が 2π の区間を「約束として」選んでるだけ。…だけど、ごねても話が進まないので、とりあえず虚部が −π より大きく π 以下の範囲という約束を受け入れて、

• 主値をそのように定義したとき、log a^b の形の対数の主値は、どうなるか？

という問題に取り組んでみたい。（続く）

チラ裏より

「チラ裏」は、きちんとまとまった記事ではなく、断片的なメモです。

• 2021-04-09　¼↑↑∞ = ½　有理数に収束する無限タワー
• 2021-04-10　目で見る i 乗　テツコのベルギーワッフル
• 2021-04-11　目で見る i 乗（その2）　2 の i 乗…
• 2021-04-13　目で見る i 乗（その3）　(−2) の i 乗、(2i) の i 乗…
• 2021-04-14　ω 乗
• 2021-04-18　1 の √2 乗は単位円上で稠密　整数の偏角も稠密
• 2021-04-28　「宇宙の実装」と日常生活　助からないと思っても助かっている
• 2021-04-07　双曲線の計算地獄…と天国（その2）
• 2021-04-04　目で見る複素三角関数cos　赤いリボンもキリリッと
• 2021-04-06　√1−z² = √1+z√1−z はOK、√z²−1 = √z+1√z−1 は駄目
• 2021-03-30　目で見る複素関数cosh　cosより考えやすいかも？
• 2021-03-31　√z²−1 = √z+1√z−1 でない　√1−z² = √1+z√1−z なのに…
• 2021-03-21　cot の逆関数　びっくり！！ 君の教科書もまっ赤なうそ！
• 2021-03-26　arccot 第2定義の4種のバリエーション
• 2021-03-17　tan (θ/2) = csc θ − cot θ の可視化
• 2021-03-06　すてきな証明　tan ((α + β)/2) = ?　ウィキペディアより
• 2021-03-01　グーデルマン関数の可視化　円と双曲線　虹の懸け橋
• 2021-03-03　∫sec x dx　グーデルマニアンの威力
• 2021-03-29　【動画作成】注意報　Vorbis/Opus音声はリスキー　直してほしいVLCのバグ
• 2021-02-12　2項定理　ばかばかしいけど分かりやすい（？）説明
• 2021-02-07　「シェルバトフの名著」とは
• 2021-01-10　フィボナッチ数列の一般項の公式　一番簡単な方法？
• 2020-12-22　なぜ木星・土星は外惑星なのに太陽のそばで合になりたがるのか？
• メモ（チラ裏）一覧