小ネタ

　時計の歴史を紹介する本で、アメリカの鉄道でかつて制定された基準の中に「40°Fからマイナス90°Fの範囲で正常に動作すること」みたいな記述が出てきて、そんなことあるかな、という疑問。

　摂氏と華氏は-40度で同じ値(-40°C=-40°F)になるので、華氏-90度というのは摂氏-40度を下回る。アラスカで過去に記録された最低気温だと-80°Fくらいまで行くらしいけど、アメリカ本土の鉄道会社が策定する基準には含まれていないはず。

　たぶん「40 - 90°F」みたいな文を翻訳したときに「40°Fから90°F」ではなく「40°Fから-90°F」みたいに訳したんだろうな、という気がする。40°Fから90°Fなら+4℃から+32℃程度の範囲だから、屋外(鉄道車両内)の温度環境としては妥当な気がする。

　セイコーのウェブサイト曰く40°Fから100°Fの範囲だそう。別のウェブサイトでは34°Fから100°Fと書いてあるところもある。会社ごと(運行する地域の気温)によって独自に基準を作っていたんだろう。

　本の中では、振り子時計の説明で、振り子の熱膨張が3桁(SI接頭辞1個分)間違って書いてあったりする。ざーっと読んで見つけた怪しい点はこの2つくらい(誤字等除く)。まあ、年号とかを除けば数字が細かく書いてある本じゃないからな。サイエンス系の本が専門のレーベルなんだから、編集者も簡単な数字のチェックくらいはしておけよ、という気はするけど。編集者ってのは内容の確認(≒検閲的な行為)は行わない、というスタンスなんだろう。科学的な内容を専門に出版すると謳っている以上、明らかに誤っているであろう箇所は著者に問い合わせるくらいしろよ、とは思うが。

　ナイトビジョンで4眼のやつはあるけど、5眼とか6眼のNVって無いのかな。正面のチューブの下方向に追加して、手元や足元が見えるやつ。6眼なら足元を立体視できるから、物が散乱している場所とか足場が悪い場所に入るときに便利そう。実際のところは重量やコストがネックになるんだろうなー。あとは、据銃したときに邪魔とか。

***

　Delta Forceで自分で撃った時に、体感で「今の絶対あたってないだろ」というやつでもヘッショ判定されてたりして結構違和感ある。エアソフトだとペーパーターゲット相手ならちゃんと狙って撃てばちゃんと当たるけど、逆に言えば照準を合わせなければ当たらない。ゲームだとそういう常識が通用しなくて、銃や追加機器で銃弾の当たり判定の大きさを増やすような処理になるらしい。なので、プレイヤー視点からしてアイアンサイトとレッドドットを比べて狙いやすさに違いがないから安いアイアンサイトを使おう、みたいな判断は駄目らしい。ゲームと現実を一緒にするな、というやつ。常識を分けて考えなきゃいけない。どちらかといえばinstinctive shootingを極めたのがFPSゲーム、という感じかな。

　見た目だけならハッキングクロー一択だけど、スキルが使いづらそうで。でも強いプレイヤーだいたいこれ使ってる気がする。まあ、これを使うから強いわけじゃなくて、強いからこれを使えるんだろうけど。FPSは自分が使ってるキャラが見えないから見た目で選ぶ理由がないんだよなー。結局自分で回復できるスティンガーが一番楽。コンパウンドボウで電撃矢やスキャナを撃てるルナも便利ではあるけど、NPCに電撃を撃ってもダメージ入り切るまで時間がかかるからその間にNPCに反撃されて、ステルスキルができない。CAR-15にサプつけて持ち込むほうが安心。あるいは、ハッキングクローのナイフを使えばいいのかもしれないけど。

　ハッキングクロー、QWERTYキーボード付きのモバイル端末とか、猫の顔が書いてある投げナイフとか、色々好きなポイントを突いてくるんよな(黒猫はブレスレットとかチェストリグのパッチとか、あちこちにいる)。ウレタンマスクみたいなやつはあんまり好みじゃないけど、とはいえ「肺に砂がたまると健康に悪いから」とか言われると納得するしかないし。Delta Forceの各キャラは経歴とか色々作り込んであるし、そのうちキャラごとに2,3分とかのアニメを作ったりするんだろうか。

　黒猫モチーフのパラコードブレスレットは普通に欲しい。イラストを再現しようとするとバックルが特注になるから大変そうだけど。いちおう、動物(特に猫)の首輪向けに猫モチーフのバックルは市販されているから、それを使えば雰囲気は真似ることはできるか。

　猫の投げナイフ、持ち手部分に小さいOLEDディスプレイがついてたり、刀身の根本にシールドケースのブレークアウトボード(2x6ピン)がついてたり、電子工作的な視点でも面白い。

　刀身の中に3本のパターンが引いてあるけど、これアンテナになってるのかな。シールド付きのやつはRFモジュールか。裏面は見づらいけど、外付けの発振器かな? クロックはRFモジュールに入ってそうな気もするけど。見た感じ電源が入る場所がなさそう。周囲のRFモジュールをクラックするならLIBとかよりキャパシタで大電力パルスを出したほうがいいのかな。使用前は鞘に入れてるからその状態で常時充電しておいて。

　ナイフ自体は2パーツで分割している感じ。刀身全体からグリップの片面と、グリップの反対側。モナカ的に分割したグリップ部分に色々(電源とか)入っているんだろう。ダイカストとかでも作れるだろうけど、個人が使うような装備なら量産するようなものでもないだろうし、付加製造で作っているのかな。時代設定的には現代より少し未来のはずだし、最前線にも金属積層造形の設備はありそう。前線を支える各種機材で必要な交換部品を必要なときに最前線へ補給するのはロジスティクス的に結構大変なので、小さい金属部品なら最前線で作るほうが効率がいいはず。造形や仕上げ(5軸CNCとか)で部品1個を作るのに24時間とか48時間とかかかったとしても、海運や陸送で送るよりは圧倒的に早いわけだし。なら個人用の特殊なナイフでもチタンとかで作れるはず。投げナイフとして使える量を供給できるかというと怪しいけど。

　DMAチート対策強化のお知らせ |『Delta Force』 | 究極のタクティカルチームシューター | PC版無料プレイ

　DMAチート、何年か前から原理的には可能とか言われてたけど、ツールとして普及するくらいまで来たんだな。しかし、結構複雑な構成だ。

　ハードウェア的には、PCIeエッジコネクタがついたZynqカードが1枚あれば、DMAでメモリを読み出しつつHDMIを受け取ってオーバーレイをレンダリングしてHDMIで出力してUSBデバイスとしてエイムボット作って、みたいなものは作れそうだが。まあ、通販で安く買える部品を組み合わせたほうが楽よな。

　PCIeのDMAってどれくらいの権限が必要なんだろうか。例えばPCIe接続のUSBアダプタに偽装したFPGAからRAMをDMAで読めるなら、USBホストでマウス操作を受け取って、必要に応じてエイムボットを適用してPCに流しつつ、RAMを読んで、みたいなことはできそう(3.0以降の高速・大容量転送を行うUSBホストならDMA転送をしても不自然じゃないし)。OSから見れば単なるUSBアダプタだから、デバイスツリーを見てチートツールを見つけるのも難しい。HDMIに壁越しの敵の位置を上書きするとか、あるいはエイムボットとして使うならメモリへの書き込みを検知するみたいなこともできないから、対策は大変そうだなぁ。プレイヤーとしてはチーター対策はゴリゴリ進めてほしいところではあるのだが。

*

　試しに黒猫の投げナイフを3Dプリンタで出力

　猫耳の先から刃の先端まで290mm。イラストだともう少し長い雰囲気かも。ベッドサイズの関係で300mmくらいが限界。分割は半分に割っているだけなので、イラストの分割ラインとは違う。本物の通りに分割しようとするとFFFプリンタでは綺麗に出力できないのでしょうがないとはいえ。

　ゲームのスクショと並べてみるとだいぶ違うけど、全体的には似てるかなー、といった程度。やっぱり紫のOLEDが特徴的だし、基板の緑のレジストやパターンの金フラッシュも印象的だから、それらが無いとだいぶ違う雰囲気。電子部品も含めてモデル化して色を塗ってやればもっと近くなるんだろうけど。GPS受信機を埋め込んでOLEDにLat/Lngを表示するような機能があれば面白そうだが。

　ちなみに、体積は70cm^3弱なので、チタンで作ると300g位になる。例えばKa-Barナイフは全長が30.16cm、重さが560gなので、同じくらいの大きさで少し軽い、くらいの雰囲気。鉄で作ると7割増くらいになるからKa-Barとほぼ同じ重さになる。もちろん、この形を強度のある素材で作ると日本では違法だが(樹脂製なら完全に合法かというと、微妙なところではあるけど)。

***

　GPSの相対論項(Δtr)、前回は一般相対論的効果と書いていたけど、これは軌道半径・離心率・離心近点角の関数であって、遠地点では重力と速度が減って、近地点では重力と速度が増えるから、一般相対論的効果と特殊相対論的効果の双方が同じ向きに作用しているので、特殊や一般をつけず、単なる相対論的効果というのが正しそう。

　受信機のクロック誤差、初期値をx=y=z=s=0として計算を始めてもいい、という話の続きだけど、そもそも普通の受信機は内部の時計から擬似距離を算出するから、sの値はせいぜいミリ秒以下のオーダーのはず。RTCがクリアされた状態では受信機の時計が無いからGPS秒数をそのまま使うとしても、とはいえ一番最初に見つけた衛星のGPS秒数を一旦RTCに採用すれば60-140ms程度の誤差に収まるから、適当なオフセットを加えて数十msとかその程度の初期値が得られるはず。ということで、s=0でもクロックエラーが±60万秒(1week)みたいな想定は必要ないはず。そもそも、普通の受信機の場合、観測量は衛星時刻ではなくて擬似距離だから、クロックエラーが大きすぎると衛星位置の計算で誤差が増えて収束しなくなるはずだし(観測量に衛星時刻を使うと、衛星位置計算の誤差はほとんど発生しない)。

　GPSの物理的な観測量が時刻じゃなくて時間(定数c倍で距離)なのが謎いんだよなー。数学的に方程式を立てたときに綺麗になるから、みたいなことなのかもしれないけど、時刻を観測するほうが後処理が楽そうな気がする。

　GPSの電離層モデル、ピアースポイント(電離層貫通点の磁気経緯度)の計算には受信機の経緯度しか使ってない。高度が上がるとピアースポイントは受信機の経緯度に近づくはずだから、正しく求めたいのであれば高度情報が必要なはずなのだが。もっとも、電離層を高度350kmの薄膜にモデル化した場合、多少の高度変化(高度0kmから15km程度まで)であれば高度の差はさほど影響はない、ということかな。特にGPSが標準で出してる2個の3次関数でモデル化した場合、水平方向での差は小さいはずだし。

　GPSの測位演算の重み付け、とりあえずsin(el)^2を設定してみたけど、いまいち期待したほどじゃない。仰角7度の衛星があると、除いた場合(仰角マスク的な挙動)では12.6m程度に対して、低仰角を含めてすべてを同じ重みで扱うと82.3m、重みをつけると46.5m。重み付けで2倍程度まで改善するけど、仰角マスクの4倍くらい悪い。ちなみに、仰角マスク+重みだと35.2m位になる。重みをつけると3倍近く悪くなる。

　GPSとQZSの中、仰角が高い組み合わせ(2xGPS+2xQZS)だと210m程度(PDOP18)、4xGPSだけで計算すると1400m程度(PDOP198)、位になる。4xGPS+3xQZSだと13m(PDOP3.75)程度で、13/3.75=3.5、210/18=12、1400/198=7、くらい。

　このIQファイルは可視性が悪いので、全天が見えているデータならもっといい精度になるかもしれないけど。

　ECEF→BLHの手法ごとの計算誤差(縦軸：メートル、対数スケール)。xyz毎に±5万kmの乱数を10万点作成してグラフ化。

　青、橙、緑をそれぞれ手法1,2,3として、手法1は「GPSのための実用プログラミング」で紹介されているソースコード(xyz_to_blh)を、手法2はWikipediaのGeographic coordinate conversionのニュートン・ラプソン法を、手法3は同WikipediaのThe application of Ferrari's solutionを使用した。

　誤差の評価はBLH→ECEFで直交座標に戻して、2つの直交座標間の距離を求めた。このため、計算誤差にはBLH→ECEF変換で発生する誤差も加わるが、1)BLH→ECEF変換はECEF→BLHに比べてシンプルである、2)すべての手法で同じ程度の誤差が加わるから比較する際には影響はないはず、という理由でこの方法を採用した。

　それぞれの手法において、経度と誤差に相関はない(経度はatan2(y,x)で解けるから当然)。いずれの手法も高度と誤差は弱い相関がある(高度が低いほうが精度がいい)。特に手法1は高度0付近以外では誤差が大きくなる。手法2および手法3では緯度と誤差に相関はほぼない(若干高緯度側が精度がいい)が、手法1では強い相関がある。赤道付近では誤差はかなり少ないが、中緯度地域では誤差が増える。中緯度地域で地面から遠い場所(地中or上空)が一番精度が悪い。

　なお、ニュートン・ラプソン法では、大部分は2回の計算で十分に収束し(差が1e-15未満)、例外的にいくつかの場合に1回または3回で収束する。2回で打ち切った場合は最大で1e-3m程度の誤差が出ることがあるから、ある程度精度良く計算したい場合、ベタ書きするなら3回のイテレーションが必要になる。

　手法2と手法3を比較した場合、手法3のほうが2桁近く精度がいい。ただし手法3ではsqrtが6回、cbrtが1回入る。手法2はsqrtが2回と1.5乗が3回入る。1.5乗はx*sqrt(x)で代用できるから、powを使わずにsqrt5回で済ませることもできる。結局、手法2と手法3では計算コストは大差ない。計算誤差は桁違いで、計算コストは大差ないから、手法3のほうが有利。ただし計算過程が複雑になるから、ソースコードをシンプルに済ませたい場合は手法2でもいい(実用的には手法2の精度でも問題ないはず)。

　手法1は、高度が-1kmから+5kmくらいの場合は最大で10mm程度の誤差が発生する。高度が低くなると誤差が急激に増える(地中なのでGPSの場合は問題ないが)。高い方は10kmで0.2m程度、40kmで0.4m程度の誤差になる。低高度エリアの単独測位なら誤差の範囲かもしれないけど、干渉させたりしようとすると問題になるかも。手法1は標高(ジオイド高)が0に近い場所かつ赤道付近で近似したものかな。手法1の計算にはsqrtが3回、三角関数(SinCos)が2回(SinとCosを別に呼ぶなら4回)、Atan2が1回(+Lat/Lngを求めるのに2回)が必要になる。計算コスト的には多少は低いけど、とはいえ精度を犠牲にするほど計算量が低いというわけでもない。

　高度対手法2(青)・手法3(橙)のグラフ(誤差はリニアスケール)

　手法2は地心からの距離に比例して誤差が増える一方、手法3はそういう傾向は見られない。厳密には、手法3だけ表示すれば地心からの距離に比例して誤差が増える傾向が見て取れるが、これはdoubleの精度の問題のような気がする(80e6m地点で誤差が3e-8程度だから、15.4桁の精度があり、doubleの有効桁数(15.95)と整合的)。もしかしたら手法2の傾向もdoubleの精度に由来するのかもしれないけど。手法3がdoubleの表現精度限界まで計算精度が出るの結構すごい。途中で誤差が加わりそうなものなのに。

　オーディオの人たち、「GPSクロックを使うと時間経過とともに音質が向上する」とか言っててすごい(ノイズをアラン偏差でグラフ化すると右肩下がりになるので、長時間使うとその分ジッターが減る、という理論)。オーディオでもRbを使ってる人がいるらしくて、それに比べてもGPSには音質改善効果があるんだそう。コヒーレント長数十日くらいないと効いてこなさそうだが。

　音速で地球を1周すると12万秒くらいだから、このくらいのスケールの反響を考えると、RbとかGPSをタイミングソースとして使うのは効果があるかもしれない。まあ、温度を1ミリケルビンくらいの精度で安定化させないと意味がないけど。

　量子論とかが提唱され始めた当時に「オカルトだ」みたいに攻撃されていた歴史を振り返ると、自分が理解できないものをオカルトだとかいって批判するのは良くないとは思いつつ、とはいえオーディオ分野(特に個人のハイエンド領域)はオカルトっぽいよなぁ。

　Visual Studioでprivate void Deconstruct(out int hoge, out int fuga)みたいなの作ってクラスの中でvar(a,b)=this;みたいに使うとDeconstructを未使用扱いで削除を推奨されるの、なんとも。

　C#で配列を変数に展開するような機能欲しいよなー。ReadOnlySpan<int>span=[1,2,3,4,5];に対してvar(a,b,c)=span[1..4];的な処理をやりたい。

　いちおうreadonly record struct Hoge(int A,int B,int C);みたいなのを用意してvar(a,b,c)=MemoryMarshal.Cast<int,Hoge>(span[1..4])[0];みたいにすればできなくはないけど、メンドクセ。複数箇所で使うとか要素数が10個とかあるならともかく、1箇所で使うだけならベタ書きしたほうが楽な気がする。