ORBITER 2010
公式：http://orbit.medphys.ucl.ac.uk/home.php
前スレ：http://schiphol.2ch.sc/test/read.cgi/fly/1002727476/l50
wiki：http://wikiwiki.jp/orbiter/
mod置き場：http://www.orbithangar.com/
CATVとFTTHとWiMAXの人は諦めてください
http://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7
どっかを固定でもらっておけばいいんじゃないの？
ゲームだからそれでもいいですけれども。
アドオンが実行できません。何が原因でしょうか？
terminating after critical error.see orbiter.log for details.
.scnを書き換えるといいよ。
一般向けの良くできたコンシューマゲームなどに慣れてなれていると違和感を感じるけれども、DirectXをVC++などでプログラミングする連中からしたらありきたりな話でもある。
慣れるしかないかもしれないね。
全自動のやつでうおおすげーとかいってるだけでも楽しい
もうやってるひと居ないかと思ったら
何人かいるのね
http://www.spiegel.de/panorama/0,1518,bild-192707-751072,00.html
嬉しそうに「放射能漏れですよ」じゃねーんだよ！ナチズムからの攻撃だったての。
メシ食って元気出せ！
Orbiterを扱うとキレやすくなるらしいね。
X-33を扱うだけで、PC経由でナチズムがケンカを売ってくる。
しかも、教授が銃撃されただのと宣伝だよ。何なんだよ？ロンドンは。
ナチス・カトリック電波通信社によると、以前にすでにロシア国内とイタリア国内で2名が銃撃を受けてるぞ。
それが具体化した東欧ウィッチ家系のガブリエラ女史の話ができないらしいね。
http://www.youtube.com/watch?v=ICXdQR1VVhw
MESHNAME="vstar"
EMPTY_MASS=300000
FUEL_MASS=3796000
MAIN_THRUST=1.33861e15
ATTITUDE_THRUST=500000
ISP=450000000
・適当な.scnを書き換え(フォーカス・カメラ・MFDの設定も変更)
BEGIN_ENVIRONMENT
System Sol
Date MJD 55308.7631206201
END_ENVIRONMENT
vstar2:Spacecraft\Spacecraft
STATUS Orbiting Earth
RPOS 5420896.41 594452.72 4401603.32
RVEL -4754.129 150.732 5834.277
AROT 2.93 39.14 -2.00
AFCMODE 7
PRPLEVEL 0:0.999979
NAVFREQ 480 0
END
地球周回軌道から火星に一直線
X-33
http://www.orbithangar.com/searchid.php?ID=1935
F4からのシナリオエディター上でvstar2の
AROT 2.93 39.14 -2.00
を
2.928 39.143 -2.00
程度に変えると良いかも知れない。
開始直後のフル加速でフォボスの火星周回軌道円内を通過する事だろう。
加速開始時刻の誤差がシビアです。簡易計算機は無いですか？
軌道要素の変更だけでは位置がなかなか合わなかったためにOrientationを変更してしまいました。
本来はきっちりと姿勢制御を行い、進行方向へ加速するべきなのですが、標準機能ではターゲットマーカーによる軌道予測と、進行方向への機首向け先が少々誤差があり、軌道予測方向への機首方向の自動補正が搭載されていません。
しかし、手作業で繰り返し処理による誤差微調整が可能な内容なので、予測自動計算機能が欲しくなります。
・・・という呪われ方。分かる？
なにしろ通常ではメニューバの回数と時間を少なくしたがりますから。
しかし、自動操縦を用いても、今度は桁数の問題が出ます。
多桁の修正・調整操作に対応した手軽な入力インタフェイスを考えなくてはいけなくなってしまうわけです。
むしろ予測できる操作に関しては一連の操作をA.I.で、という話まで出ますね。
そうなると今度はA.I.による操作の処理時間、という問題が出るわけです。
・・・そして、だれもいなくなった。
学生時代だけですよ、こんなもの。
暇な人にはそれが分からんのです。
興味を持つ人の、大半の人が忙しくなるｗｗｗ
しかし、だ。
見てのとおりだ！諸君。
何が進んだのか？
しかしサボります。やる気がおきません。
・・・それでいいのか！？
無料だからな。
しつこく開発が遅れている理由を問いますが、シミュレーションシステムは他国依存だからですか？
しかし、ごちゃごちゃとうるさい南雲艦隊だよ。アリゾナとか世界標準時とか択捉とか。
悔しかったら南雲艦隊のモジュールをOrbiter用に作りやがれ！
あの人、時のアメリカ駐在者の関係者でしょ？
ひどいよな？海軍連中は。その後に仙台の空港まで水没させただろ？
構造がありえないほどいいかげん。
どうやったら揉め事を起こさずに安定するんだよ？
しかし真珠湾攻撃は12月だったぞ。なぜ今頃？
もしかして推考しただけの地方標準時の詳細化の話でそこまで揉めるのか？
分単位の標準時地域があるのであれば、マイクロ秒単位やナノ秒単位の地方標準時があってもいいはずだというだけの話なんだけれどな。
しかもハワイの標準時はハワイ現地主導ではなくアメリカ本土依存であるという点が問題であり気に入らないと言わんばかりなんだろ？
滅損扱いしたいから新機種の手配予算をよこせとごねてるんじゃないのか？
wikipediaでは、F-104のユニットコストは
142万USドル（F-104G）
って書いてあるね。
当時1ドル360円か？511,200,000円かな？
1機5億円程度で買えたんだとさ。
ファントム２の1機10億円以上で「高い！高い！」って話だったんだろ？
今だと最新の現行のヤツが1機120億円ですか？困った予算消化方法だよな？
人件費換算してみろよ。笑えるだろ？
まずはそこからだろ？
なんて良い時代だ
空↑↓空
←■■←
→■■→
空↑↓空
PSP用のスーファミエミュ上のとか？
独自アーキテクチャのバイナリデータに【興味あります】
最速クリアマクロ+A.I.化に特に興味が出るよ。
Orbiterの作者さん、MAMEに興味持ってたらしいぞ。
過去のハードウェア資産をソフトウェアでエミュレーションしている状態に感銘を受けたそうだ。
カメラの視点の設定についての記載がある。
.scn上に設定することで、多彩なカメラ視点を扱うことが可能。
例：視点の中心点を追尾で固定
BEGIN_CAMERA
TARGET DG-01
MODE Extern
POS 13.73 -48.23 -0.00
TRACKMODE TargetTo Earth
FOV 50.00
END_CAMERA
TARGET(DG-01)から一定の距離(13.73 -48.23 -0.00)を保ち、向こう側にTargetTo(Earth)を保ったままの状態にカメラを固定。
ただしTRACKMODE TargetToでは中心点を1直線の軸上に持ってくることを優先してしまうために、POSのデータは直線距離に置き換えられてしまう。
たとえばDG-01から5m上空20m後方を保ったまま地球を追尾するようなカメラ設定は不明。固定視点では可能(なはず)。
BEGIN_CAMERA
MODE Extern
POS 0 0 0
TRACKMODE Ground DG-01
GROUNDDIRECTION 100.00 45.00 10.00
FOV 50.00
END_CAMERA
どこをどう触ればどうカメラ視点が動くのかが分かりにくいが、対象物の座標原点以外のフォーカス中心点での視点設定も可能。
興味が出たが、日本語解説ページが上位に出ていないな。
航空機制御をマクロなどでA.I.化可能ならばやってみたい。
手動操作？飾りですよそんなもの。
やるとやってるで自動車の走行音や低空飛行するヘリ騒音とか、子供の騒ぎ声やスズメバチとか右翼の街宣車などの騒音の増大などで邪魔するくせにｗｗｗ
ということで、結局作者依存なんだろ？だったら俺に言うな。
分かりやすいように設定情報をまとめて行っているだけだ。
実機で誤差が出たとかでファビョって地震遊びとかされてもらっても困るんですよ。
任意桁高速演算関数を出さないのは、出さない人のやり方なんだから。
Orbiterもそこで詰まるときがあるらしいよ。
無印かAFを持って無い場合はね
説明すらまともに出来ないようなチョンゲーレベルのクズゲーなど、パチンコ並にどうでもいい。
チョンゲー屋も能書きでも書いてろよ。
なんかOrbiter以外にも色んな事で煮詰まってるみたいだね。
俺で良かったら話聞くよ？
平行線のままの言葉。会話なき、進捗の薄い状態。
「扇動した」「計画爆破した」「漏洩した」「お前に言われると反発する」「ただ、何か気に入らない」「犬である」「『貧乏揺すり』とは何事か！？」
そういう態度は「いいわけ」「ダダ」と断定し、投げ捨てるだけだ。
それとは別に「大震災」をどうしたいのか？と言わざるを得ない。繰り返したいような態度の者たちがいる。
脅す担当者になぜ脅させたまま、本業をやらないのか？
本業がスクラップアンドビルドだと言い張るだけか？
シナリオエディター上では
2011/06/11 06:18:22が
55723.262757(MJD)となっている。
明示されていないが、マニュアルには説明がある。TDBという時間表現のようだ。
セーブファイル(scn)上では、
BEGIN_ENVIRONMENT
System Sol
Date MJD 55723.2627567593
END_ENVIRONMENT
となっている。
TDBについては
All dates are referenced to Barycentric Dynamical Time (TDB), a common time scale for
describing orbital events. TDB is similar to Universal Time (UT), with an offset of currently
66.184 seconds.
とOrbiter.pdfに記載がある。
・・・面倒くさいので翻訳しやがれ！
それと、MJDの桁位置と秒数の比較、秒の桁位置とMJDの桁位置との比較もよろしく！
MJD以外に、JDでもいいよ。
Orbiterを見ると、こんな話ばっかり。
フォーマットは64bitだそうで、1秒が32bitのようだ。
http://www.venus.dti.ne.jp/~yoshi-o/NTP/NTP-SNTP_Format.html
そうなると、1秒の分解能が1/(2^32)の1/4,294,967,296となり、とりあえず10進換算では9桁保証となる。
1ナノ秒だろうか？
Orbiterでは開示できる情報として、MJDで日数に対し10桁あるわけだ。
さて、OrbiterのMJDの最右端1桁が1進むと、いったい何m進むだろうか？
地球周回軌道で良いよね？たとえば7900m/sで。
同様に、1ナノ秒でどれだけ進むのか？という問題にもなるね。
ドッキングを考えた場合の誤差にならないかな？
ハッチ同士の傾き差が何度で、どれだけの距離差が出るのかな？
NTPだと、1ナノ秒を保証するときの誤差を補正するのに、何台の同期と同期確認が必要なのか？
も問われかねないので、もっと桁数を増やさないと安全管理上は安心できない。
秒未満の桁数を増やすと同時に秒カウンタの桁数も増やさないといけない。
その際に「増やす桁数が見えにくい」という問題があるようだ。
1年は365.25日で換算すると31,557,600秒となる。
32bitでは136.09930083403047126524197023855年となるようだ。
つまり2進33桁目に1桁を増やすとおよそ136年増えるのでとりあえず1桁でいいが、33bitというウザい桁数になってしまうようだ。
・・・何でこんな話？クロックオシレータ単体でナノ秒保証できれば良いじゃないか？
セシウム流出と言われても、2世代ほど前の原子時計の話だ。
9,192,631,770Hzだろうか？
イッテルビウムでは2009年で518,295,836,590,864Hzだそうで、10進14桁の秒分解能は保証していると言える。
ストロンチウムでは429,228,004,229,875Hzだったそうだが、クロックオシレータにその分解能が封入されるのはまだ先のことだろうか？
現行のクロックオシレータでも、運転時間で精度を多少調査する事が可能となっているが、あくまで指標が基準となっている。
アプリケーション上の秒分解能表示を細かくしない事には、細かい精度の保証が難しい。時計の桁数を細かく表示するようなものだろう。
クロックオシレータは精度を一致させるのが難しく、製造数と分類精度に由来すると言われる。
販売する以上、精度が合った製品がある程度まとまっていないと販売しにくいわけだ。
上記のHz数のように、細かく桁を持っていることを基準を元に確認し続けなくてはいけない。
ちなみにNIC搭載のクロックオシレータが安価供給品の中では比較的精度が高いといわれている。
物質研究の世界観では、過去の流行が流出と騒がれる事があるようだ。
DB利用でデータレコードにタイムスタンプを出来るだけ大きい桁数で持つという方法もある。
「まだナノセカンド止まりのカウンタ？」
ミリセカンドやマイクロセカンド止まりの言語に立場など、あるのだろうか？
そして、項目の名称をどう持つべきなのか？
.millisecond
.microsecond
.nanosecond
.picosecond
そして、その先を行く.femtosecond
レーザー分野では日進月歩で一般化を進めることだろう。
.attosecond
.zeptosecond
.yoctosecond
すでに挑戦的な連中は、項目名を決め、その項目名を扱うようにしている。
それは2進でbit数を基準に計算すればいいという常識を一般化する手段でもあるのだろう。
シナリオエディタでNOWを取るとPC上のローカル時計を基準としたその場のOrbiterTDBが取れるが、それがJST - 9:00:00 + 66.184という事なのだろう。
それは良いのだが、うむ、桁数の話。
冥王星でさえ、太陽から29.574 AU-49.316 AUの距離にあるということだ。
天文単位(au)でさえ149,597,870,691-149,597,870,700m程度と誤差があるが、
仮にWikipedia上の値である149,597,870,700mで換算すると
49.316auでは7,377,568,591,441.2mとなり、光速で24,608.919919663889609924743336939s
すなわち6.8358110887955248916457620380361時間で到達ということになる。
光速をlsとした場合、平均速度が24,608.919919663889609924743336939lsで1秒で到達ということになる。
換算するだけだが、
60秒の場合は約410.14866532773149349874572228217ls、
60分の場合は約6.835811lsということになる。
Orbiterでは時間分解における制御精度がまだ低いだけで、加速も移動も可能となっている。
1分で冥王星に到達する宇宙船の制御を行う場合は、制御精度として光速の410倍程度が必要ということになる。
わずか4桁程度であり、13桁程度だと目される。
秒分解能が13桁あれば、1分で冥王星に到達する宇宙船の精度を扱う事が可能だろう。
MJDでは+6桁となり、日分解能が19桁程度だろうか？
lsの分解能を日の秒数で換算すると25,902,068,371,200となる。ただしm単位である。
1/25,902,068,371,200は3.8606955462749079811988045656819e-14、
0.00000000000038606955462749079811988045656819...となり、小数点以下13桁目に数字が出る。
それをさらに1/60すると1分あたりということになる。さらに1/60すると1時間あたり、さらに1/24すると1日あたりということになる。
1日あたりでは4.4683976230033657188657407407407e-18となる。mまでの分解能の場合である。mmで+3桁、μmで+6桁だと言われる。
20桁～23桁となる。さらに、運用時間を延ばせば延ばすほどに時間分解能を増やす必要がある。
なにしろシミュレーション性能は時間分解能とOrbiterでいうワープ性能だと目されるわけである。
2^67が147,573,952,589,676,412,928となり、10進20桁保証となる。
秒分解カウンタデータを67bit持つ必要があるわけだ。
しかし誤差が考えられる。
1ステップカウントあたり67bit項目に+1し桁上がりにも対応し続ける仕様となるわけだが、
それが1秒-1ステップカウントで全bitが1になる前提となる。
もちろん誤差が出るので、対処は要る。
そのため、128bit程度を持った方が安全だと目されるわけである。
bitカウンタのbit数は仕様決定者によって変わってくる。
128bit程度は持った方が安全だと目される。
128bitは2^128=340282366920938463463374607431768211456、
1/340282366920938463463374607431768211456=
+2.93873 58770 55718 76992 18413 43055 61419 45466 63891 93021
88037 71879 26569 60431 48636 81793 21289 0625
e-39
となる。秒数である。小数点以下38桁目に数字が来る。
1bit目に+1が行われる条件が、上記の秒数経過後の表現であるということになる。
その時間経過に対し、誤差の確認と補正を繰り返すという事になる。
その前提で、128bit分の1bit秒経過後に天体の座標がどう動いているのかを設定し確認するわけである。
人工天体もなおさらである。
はしょると1ミリ秒毎などにデータを取り並べることになる。
再計算により、座標表現が可能となる。
移動を表現する場合は直線を座標点同士で繋いで描画する。
細かければ細かいほど、見た目の誤差が少なくなり、実態としての精度が表現可能となる。
(JDの場合はMJDに対しさらに日数の小数点以下に0.5が加わる。)
しかし1秒はMJDで1.1574074074074074074074074074074e-5という面倒くさい値になる。
1秒経過の表現はMJDに+0.000011574074074074074074074074...となる。
おかげで、実態としてMJDの小数点以下が5桁程度では安心できない。
失敗して1秒をMJD+0.00001などとしてしまった場合、秒あたりMJD+0.000001574074074074074074074074...の誤差が出る。
累積そのものではなく、基準の値を元に再計算する必要がある。
そのために現行のOrbiterでは.scn上にデータを出すときには小数点以下が10桁のMJDを使用しているようだが、
実際に計算を行う際にはもっと桁数が必要となる。大きければ大きいほど良い。
MJD+0.0000000001は0.00000864秒である。
1/299792458の3.3356409519815204957557671447492...e-9、
0.00000000333564095198152049575576714474918511792581519845972...
の2590.20683712倍となる。
MJD+0.0000000001は光速の2590.20683712分の1の精度と言えるだろう。
0.000000000864/(1/299792458)
は
0.259020683712となり、光速を超える単位となる。
MJD+0.00000000000001は光速の1/0.259020683712倍の分解能となり、およそ3.86倍の分解能となる。
小数点以下は14桁である。まだまだ冥王星まで24,608秒ほどもかかるほど粗い分解能である。
秒数では小数点以下12桁となる。
これを基準に桁数を増やしていくことを考える。
MJD+0.000000000000001は0.0000000000864秒である。
0.0000000000864/(1/299792458)
は
0.0259020683712となり、光速の1/0.0259020683712倍の分解能となり、およそ38.6倍の分解能となる。
小数点以下は15桁である。秒数では小数点以下13桁となる。
分かるかな？単純だろ？データ上の桁数を増やすだけだ。
「その精度で宇宙船を制御する」と言いたい。
シミュレータが現段階では対応していなくても、計算した結果をシミュレータ上で再現することは可能なわけだ。
桁数だけで言えば、そんなにシビアな桁数ではない。
座標基準の原点と解像度をどうするのか？という点はある。
m換算で原点がその付近の重力点という観点。
違う原点を元に計算した座標同士で換算するために桁数を増やすという観点。
冥王星で太陽原点のm基準座標では+-13桁付近、um基準座標で+-19桁付近、座標の+-で+1桁、xyzかrφθで×3項目で計10進60桁程度、という事になる。
まぁ地球と太陽の距離差は12桁m程度なので、+12桁mしたところで+-13桁m範囲内だろう。
銀河系重心などというまたたいそうなデータ基準を持ってくると、桁数も増えてちょっと大変だろうが、
太陽系内程度であれば冥王星程度の距離が最低基準であれば問題がないかもしれない。
15桁日数分解能を加えると20桁データとなる。
20桁日数分解能を加えると25桁データとなる。
25桁を60桁とそれぞれに+-足すと85桁データレコードの出来上がりとなる。
5572370833333333333333333+0000000000000000001+0000000000000000001+0000000000000000001
MJDに正しくドットを加え、座標にもドットを加え、区切りをスペースで区切ると単純に10進92桁+改行のデータレコードとなる。
55723.70833333333333333333 +0000000000000.000001 +0000000000000.000001 +0000000000000.000001
といったところだろうか？
MJD+0.00000000000000000001は、言ってみれば光速の約3,860,695.5462749倍速のワープ航法を示唆しているというわけだ。
1秒で考えると約1,157,407,407,407,405m/sとなる。
しかし、これではケンタウルス座アルファ星 A,Bの4.37光年(4.365±0.007光年)
バーナード星の5.97光年(5.96±0.01光年)にも満たない。
1光年が9,460,730,472,580,800mとした場合、ケンタウルス座アルファ星が約41,296,088,512,815,192m、バーナード星が約56,385,953,616,581,568mとなり、
2桁ほどだがまだまだ桁数が足りないというわけだ。
25桁日数分解能を加えると30桁データとなる。
座標データが近傍恒星クラスでmで17桁、umで23桁となる。
30+24×3で102桁データレコードの出来上がりとなる。
557237083333333333333333333333+00000000000000000000001+00000000000000000000001+00000000000000000000001
MJDに正しくドットを加え、座標にもドットを加え、区切りをスペースで区切ると単純に10進109桁+改行のデータレコードとなる。
55723.7083333333333333333333333 +00000000000000000.000001 +00000000000000000.000001 +00000000000000000.000001
といったところだろうか？
MJD+0.0000000000000000000000001は、言ってみれば光速の約386,069,554,627.49079811988倍速のワープ航法を示唆しているというわけだ。
1秒で考えると約115,740,740,740,740,740,740.74060386504m/sとなる。銀河系の直径と目される距離には満たないが、桁数は近い。あと1桁で満たすことになる。
しかし、残念ながらこの距離になるともはや天体の座標データが曖昧になっている。
そのデータを投入していくという作業が発生し、膨大な作業量になると目されるわけである。
もはや銀河系重心基準のデータエリアとなる。太陽系力学時(TDB)の基準と異にするデータ体系となる。重力基準ももっと調整しなくてはいけないエリアだろう。
摂動点か重心点かが曖昧な状態の天体が多い状態では座標が扱いにくいことになる。
見える星なので宇宙船で近づいているつもりでも、誤差が大きいのでいつまでも同一の視野角に対しほとんど大きくならないという観点にもなるだろう。
前提となる天体の座標の設定が要るわけだ。
しかもそれが複数にわたり、どこまで設定すれば良いのか？という範囲が分かりにくいことだろう。
φは+-(1/180)、θは+-(1/90)という事になる。
109桁のデータフォーマットの場合、ドットを2つ分減らして10進107桁+改行となり、
55723.7083333333333333333333333 +00000000000000000.000001 +00000000000000000000001 +00000000000000000000001
で、距離1um、φが0.0000000000000000000018度、θが0.0000000000000000000009度といったところだろうか？
桁数が同じ場合、φとθではθの方が分解能が2倍になるのはお約束である。一般にはφの分解能が高いほうが好まれるが、わざわざ変えるほど粗い桁数とはならない。
角距離計算をしてみれば分かるが、半径1auの0.0000000000000000000018φは(2πau×0.0000000000000000000018)であり、
1auを149,597,870,700mとした場合、円弧で1.6919120577016648070181676498754e-9mとなる。0.0000000016919120577016648070181676mであり1-2nmだろうか？
1,000倍しても1-2umであり、誤差としては安心できる値である。
データコンバートする前の座標基準データとして考えた場合、桁数が多い方が安心できる。
通常は「宇宙船を目標点へどう輸送するか？」という観点が先行し、その目標点を複数持ち、軌道で繋ぐはずである。
xyz座標で
55723.7083333333333333333333333 +00000000000000000.000001 +00000000000000000.000001 +00000000000000000.000001
の30桁+(符号1桁+数値23桁)×3でデータを持った場合、
日数は1桁余分に見て17bit、131,072日、およそ206年間有効の値とし、
日分解能は84bitで1/19,342,813,113,834,066,795,298,816の分解能とし、5.1698788284564229679463043254373e-26日を最小単位とする。
これは4.4667753077863494443056069371778e-21秒に相当する。
カウンタ制限を2進のbit数のMAX値にするか、それとも10進の桁数の最大値にするか？という選択問題はある。
10進の数を含めるbit数で考えているので、10進の桁数の最大値にするのが妥当だろう。
座標分解能は各軸に対し、10進17桁と小数点以下10進6桁となっているので、+-で整数部58bit、小数部20bitという事になる。
合わせると、17+84+(58+20)×3で219bitとなる。1レコードが28Bという事になる。
MJDの分解能と同様に、10進の桁数の最大値をカウンタ制限値にするのが妥当だと思われる。
55723.7083333333333333333333333 +00000000000000000.000001 +00000000000000000000001 +00000000000000000000001
の30桁+(符号1桁+数値23桁)×3でデータを持った場合、
日数はxyz座標と同様に17bitと84bitとする。
座標分解能は距離が10進17桁と小数点以下10進6桁、角度が符号1桁+10進23桁となっているので、
距離をxyz座標と同様に扱うが、+-がなく整数部57bit、小数部20bitという事になる。
整数部を58bitにしても、10進では値の分解能は増えるが、分解能の桁が増えないので意味がない。
桁数をxyz座標と合わせる場合には整数部を58bitとしてもいい。
角度分解能を10進23桁持っているので、+-で78bitとする。
分解能は10進で151,115,727,451,828,646,838,272で+-が付く。
xyzと桁数を合わせる場合、17+84+(58+20)×3で219bitとなる。1レコードが28Bという事になる。
10進の数を含めるbit数で考えているので、10進の桁数の最大値にするのが妥当だろう。
では、今度は秒間に処理可能なデータレコード数をデータ量で考えてみる。
1GBを基準にすると1024^3なので、1,073,741,824となり、
1,073,741,824/109では9,850,842.4220183486238532110091743で
およそ900万レコード以上のデータレコードが処理できる。
1,073,741,824/28では38,347,922.285714285714285714285714で
およそ3800万レコード以上のデータレコードが処理できる。
2GBではおよそ1800万レコード以上と7600万レコード以上、
4GBではおよそ3600万レコード以上と1億5200万レコード以上のデータレコードが処理できることになる。
メモリアクセススピードが2,000MB/sか？4,000MB/sか？といったところが基準となる。
それらの座標点を直線で繋ぐと見た目が曲線になる。
たとえば1億5200万接点の曲線描画である。
・・・たいしたことない？こんな処理？
随分前からこのスレにいるけど
おまえの書き込み気持ち悪がって回れ右した奴が何人いると思ってんだ
世界の平和に役に立たないけどな。
その後に沈みそうで4/5ごろに書いたかもな。
お前、気づけよ。Orbiterのネタは「日本語に限らず外国語が苦手」。
なので「勝手に調査しとけ」「アドオン作ってくれ」になる。
関わってるヤツは、みんな食らっている。
離れると安穏。知ってるか？ヤツが日本語化を2003年とか2006年に止めたのとか。
「なんか、嫌われる～」だったんだろ？ｗｗｗ
割り切れよｗｗｗネット上の相手は「へのへのもへじ」なんだよ。
好き放題書けば良い。
負けるか！クズ衛星屋なんかにな？
http://www.orbithangar.com/searchid.php?ID=5295
XR-5は試作機なので特に問題はないかもしれないが。あの事件ではDG-IIIだったような？
･･･と思ったらあったｗｗｗ
http://www.orbithangar.com/searchid.php?ID=445
航空機事故調査委員会-開示情報
http://jtsb.mlit.go.jp/jtsb/aircraft/kensaku/detail.asp?ID=1966
・・・無無無。
http://jtsb.mlit.go.jp/jtsb/aircraft/new/air.asp
確率論で語られる場合もあるのでご用心。航空機は0.x ppm程度だろうか？
それでは、宇宙航空機では？
OPMと言われて、オッペンハイマーを思い出すご時勢。
コメートの試験待ちの日々が、かつてのように続いているのだろうか？
X Position vector X-component KM Yes
Y Position vector Y-component KM Yes
Z Position vector Z-component KM Yes
X_DOT Velocity vector X-component KM/S Yes
Y_DOT Velocity vector Y-component KM/S Yes
Z_DOT Velocity vector Z-component KM/S Yes
と言われても、時間+XYZしか出てこないかもしれない。
7項目座標表現は分かりやすい座標表現方法ではある。
時間分割詳細度は、データ搭載エリア依存であるといういいわけが可能である。
「原点は！？原点は！？精度の基準だから！」
と聞いても、誰も答えてくれない。自分で決めろと言われるらしい。
しかし画像で見れば、一瞬で理解可能だろう。
そして軌道管理側は有利であると言われる。
日本語で理解しよう。
かぐや（SELENE）プロジェクト報告
http://repository.tksc.jaxa.jp/dr/prc/japan/contents/AA0064860000/64860000.pdf
つまり「座標データの保証があやふやである」ままとなっている。
しかしCelestiaへの座標データのフィードバックは行われたようだ。
さて、座標遷移をどう読み解く？
http://edu.jaxa.jp/news/20071218.html
データフォーマットを抜粋してみる。
このような座標遷移データはあまり開示されないので参考になる。7項目形式となっている。
＞2007-09-14T02:16:00.000000 3.381801563861468E+03 -4.822172015202145E+03 -3.237785869454149E+03 8.719308565739372E+00 5.978328345445631E+00 -1.899660407981034E+00
見て分かるとおり、座標は16桁実数のDouble値だ。
KM単位だとフォーマット定義にあるので、約370,000kmでは6桁となり、km未満が10桁で表現可能だろう。
座標軸毎での距離だがum(マイクロメートル)の1桁下までの実数表現となるかもしれない。
見たところE+05までしか出ていないかもしれない。そうなると2桁下までの実数表現となる。
時刻は秒の少数が6桁でus(マイクロ秒)までのフォーマットとなっている。
地球原点での太陽周回軌道での天文単位程度の距離基準では9桁kmであり、Double値にしてしまうと3桁ほど精度が下がる危険性が懸念される。
かぐやから3年以上経った今、SELENEに限らず、どのようなさらに詳細なフォーマットで開示された座標遷移情報を見ることができるのだろうか？
もはや実数16桁ではナンセンスと言わざるを得ないだろう。
誰かに許可を受ければ良いのだが、なかなか許可を取れないために詳細な座標遷移情報が出せないようだ。
たとえばアドオン類のFlightsデータ、とくに.posをいちいち見てみれば分かるが、1プロジェクトの全行程を網羅したような詳細なトレースを行ったデータはほとんどない。
調べると分かるが、Orbiter上で表現する上でのデータ的には大したbit数にならない。
理系高学歴エリアになってしまい、学派の壁が無いと軍事介入が懸念されるエリアのようで、情報をまとめることができても開示を後押しする組織が無いと開示できずに封印したままになっているようだ。
情けない話である。
解説を含めて、いちいち翻訳が必要となる。
「何のために英語だけで表現をするのか？」と問い続けると、英語原理主義という日本語退廃理論が浮かび上がってくる。
しかしデカルト系宇宙座標表現はNASAのデータフォーマット上にあるにもかかわらず、日本ではマイナーである。
「ざまぁみろ！日本人。」なままである。
Orbithangarを(Self-)destructで検索したところ、汎用のMFDはまだないようだ。
モジュール的には単に別の宇宙船や天体などにフォーカスを移し、該当の宇宙船モジュールを削除するだけだろう。
ただしその際に宇宙船規模や大気条件に合わせた爆発エフェクトが掛かると面白いかもしれない。
ま、どうせ作れないし作る必要もないだろうけどな。
軍事擁護の宇宙開発案件によそから金が出るはずが無い。
爆発する対象となるモジュールが限定されていれば面白いだろうなｗｗｗ
＞爆発する対象となるモジュールが限定されていれば面白いだろうなｗｗｗ
上記は基地内意見だが、何か？
本当、よくやるよな
http://www.orbithangar.com/searchid.php?ID=4197
2010年版で起動させてみたヤツはいるか？
そもそも外国人に作らせているのか？アドオンを含めて設定が分かりにくくて仕方が無い。
モジュールの設計情報はいわずもがな、Flightsの国外経由リークはないの？
お前、パチンコ依存しすぎだ。役立たずのチョンなりに情報を隠蔽しろよ。
おかげで高速道路上で命令にあわせて大渋滞しちゃうぞ。
いいからアドオンを使ってやってみろよ。
本当に落ちたらおおはしゃぎだろうが？
怖くて使えないんだよ。
落ちたらお前のせいでいい。
着弾軌道のFlightsなら出せるのか？
むちゃなモジュールにしないとゴミを操ってケンカを売ってくるだろ？
最初からケンカを売った方が良いのか？
鉄砲の弾はガキどもに売れば国を荒らすからいい。そう国が教えてきたのか？
足が見えるだろ？ホモやゲイ。
翻訳してみろ！
とか書けばいいだろ？
色々と聞きたいんだけど、スレの雰囲気が全くつかめない。
Orbiterと関係無さそうな話ばっかりだし・・・
日本語で情報を開示する上で誤魔化しを書いているに過ぎない。
そのくらい圧力が来るんだぞ。分かる？
影響力が分かるだろ？
ダンテ・神曲より
http://ja.wikipedia.org/wiki/%E7%A5%9E%E6%9B%B2
＞天国篇 Paradiso
＞プトレマイオスの天動説宇宙観に基づき、ダンテは天国界の十天を構想した。
ダンテたちは神たちと戦い、神の座につくのである。
それは現世において、天体パラメータで表されるのかもしれない。
分かりやすいね。
結局、クズサイトだな。
http://www.sponichi.co.jp/society/news/2011/09/11/kiji/K20110911001597080.html
＞飲みに来たが、基地に帰るお金がなくやった。間違いありません」と容疑を認めているという。
魔避けで警察依存？
Orbiterは他国軍事なので軍事じゃねーっての。俺、脅されすぎ。
Mが5972580130779281493113409.97087134243553935964901765700106685206717571892643...、5.972580130e24 kg
となるかもしれない。
計算式は？
「a=～で書かれているが、発見できるかな？」と問われる。
「関数・逆関数の宝庫だが、君たちはえげつないほどに参照するばかりでフィードバックしないのではないか？」
と問われるわけだ。
たばこ商人は、えげつないやり口だよな？
1960年代、1970年代、スペイン(フランコ)・リビア(カダフィー)・キューバ(カストロ)が親ソ対米戦線を張ったのは記憶にあるかもしれない。
スペインに関しては、フランコの死去によって収束したと目される。
ソ連亡き後、リビアの次はキューバも狙われるのだろうか？
作者はキューバ寄りのイギリス人のようだが。
もちろん、彼らが狙われるのは、時の軍事革命家たちだったからかもしれない。
その陰で笑うのは、いつでも軍事傾向の強い宇宙開発技術者。
文系がいかにお粗末か？と言われる背景は、子供たちに分かるように宇宙開発技術を説明できないという点だろう。
フランコ将軍(スペイン)
http://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Franco0001.PNG/200px-Franco0001.PNG
カダフィ大佐(リビア)
http://livedoor.2.blogimg.jp/potemkin01/imgs/3/5/3564c450.jpg
ノリエガ将軍(パナマ)
http://www.latina.com/files/0108noriega_article.JPG?0
カストロ議長(キューバ)
http://castro7015.web.fc2.com/castrosirokuro.bmp
・・・Orbiter作者との関係が問われる人々である。
サラリーマン然としたゲバラ
http://stat.ameba.jp/user_images/20110713/00/yoshikazudebori/af/55/j/o0375050011346755567.jpg
軍人であるゲバラ
http://www.iza.ne.jp/images/user/20090112/400769.jpg
若くして死んだために、一部で英雄扱いだった。
・・・今の時代の若き革命家たちは、いったい何を求めるのだろうか？
きっと、パチンコ屋金正日ではないことだろう。
http://3.bp.blogspot.com/-h_9JnOP9PAw/TjGongArKYI/AAAAAAAAAKs/i9PWcDPlsPA/s1600/327e6eb74dc17f09cdb82e90d5980437.jpg
戦争勃発など恐れないという恐ろしさが、アインシュタインの本質だったのだろう。
たとえISS軌道であっても宇宙項・宇宙定数を調べると、アインシュタインが降臨するかもしれない。
彼が当時説いたのはΛ。
「そろそろデカルト宇宙を図で画像で構築するかどうか？」
と問われるわけだ。
まあきちがいだから意味わからんことするんだろうがな
まあきちがいだから意味わからんことするんだろうがな
まあきちがいだから意味わからんことするんだろうがな
100～のスレッドの続きを読む
