>>47
復興資金は税金で
→科学技術関連予算を優先的に削減
→大学予算減
→サムチョン研究員「共同研究させてくれニダ」
　（カネだけだして、技術、特許は頂く契約、実態は委託研究）

あれ？前からトロンじゃなかったっけ？
はやぶさもOSがトロンとか聞いたけど？

ウインドウズはＧＭ車の乗り心地。そのドン臭さにいらつくたびに、
もしトロンが世の中にもっと出ていてくれていれば、トヨタ車並みの
快適さだったはずと思う。

BC系の任意精度演算をLinuxのウィンドウアプリ上で汎用に利用できるようにしてからLinuxを語っていただきたいものだ。

>>41
デジタル録画やら複雑な制御やらで対象の規模が大きくなってきたんで、
iTRONもだんだんLinuxやリアルタイムLinuxに切り替わってるよ。

>>54
BC系ってなに？

画面表示可能桁数と表示速度に限界があるので、小数点以下の桁数を指定するのがBC等のprecisionのやり方。
一般の任意精度は表示したいフル桁数を指定する。
こっちのほうが高機能だが、BC等では対応していない。
コンソールのみで動くBCを単純に機能拡張した場合はBC系になるはず。

・・・高橋信者か？だったらlmを移植すればいい。

>>11
一枚噛んだと言われる禿糞朝鮮人は取り敢えず死ねと

今のJAXAの軌道設計では実数2,000桁以上、3000桁などと言われているぞ。
リアルタイムで2,000桁以上を扱えよ。

あのハゲ爺は岐阜県民だと言われているからな。

>>50
価格が高すぎだろ、あのOS

TRONもLINUXに置き換わって役目を終えつつあるって感じだけど
どうなんだろうね

>>54 >>57
有効桁数？

それは管制の領域で、実機のリアルタイム制御には
関係ない気がするんだけどなあ。
燃料バルブや姿勢制御でそこまで精度要るんだろうか。

2進2,000桁で16進500桁か？10進化で表示603桁か？
各項目に2,048bitを与えると？
さらに時間分解能を2,048bit与えると？ｗｗｗ

「そのくらいは欲しい」と言われるんじゃない？

>>56
コムデギャルソンとかパパスとかメンズメルローズとかそういうやつ。

ウィンドウズはビジネスモデルで勝ったんだよ。だいたい米企業はそれで勝つ

処理速度を上げるためにチップを分けて扱う場合はHAL形式か？
初期のスペースシャトルでは3つだったが、コンステでは5つだったか？
帯域が増えれば全部送受信すればいいんだけどな。
そのためにはオシレータの分解能がいるんだろ？
オシレータの桁数がいるわけだ。何桁？

オシレータの表現可能桁数は、同一指標のオシレータの生産数に置き換えられるわけだ。
どうどう巡りだな。ppt？

・・・ここで中国依存だろ？めんどくさ。自国内でもやれよ。
Windowsの罠であるNTP依存も、現状ではナノセカンド止まりだからな。
調整項目が多い。

内部分解能を上げるとミスしにくい上に、移動速度も増せるしさらに詳細制御が可能になるはず。
高級品であることをアピールするようなものだ。
ダイソー手提げ袋とＬＶバッグの違いみたいなものだ。
もちろんデータ送受信上で処理が追いつく桁数である必要がある。
データを切り取ってしまうと無駄な処理になってしまうからな。
各制御部分を担当していて、参考とする入力データの桁数が足りないなんてありきたりだろ？
テレメトリとか言って誤魔化しかねない部分だな。
そういうのを回避するためでもあるはず。
通常は全うするべき桁数と、目標とするべき桁数と、よそで達成されており、一般的に指標となる桁数があるのでは？

チップ性能が高ければ内部圧縮して別チップで内部解凍するんだろ？
同じ処理を通信上でも行うんじゃないの？
16進圧縮に限らないだろ？時間軸側で圧縮でも5次元でも6次元でも圧縮すればいいのでは？
通常では複数項目を合わせて圧縮する程度じゃないの？
単一項目上で桁数が増えるとその分、圧縮率が上がるのでは？

チップのピン数を増やせという話にしかならないなｗｗｗ

しかし計算速度なんて、内部で持っているコンスタント値の種類と桁数が重要だよな？
一般的に何種類くらいの項目を持っているんだろうか？
当然、全て2進化された値だろうけれども。
piみたいに、あるだけ長大桁で開示すればいいのに。あくまで検証用だけどな。
√2から√2000まで、全部を実数で2,000桁まで計算すると何秒？
普通は特に割り算傾向の計算は事前に計算しておき、実数データで持つわけだ。
計算を効率化すれば実数データから持ってくるより速いかも？
しかし開発に時間が掛かるかも？
√20に対し√2000は10倍でしかないよな？
√20の実数を10倍するのと√2000の実数を引っ張ってくるのとではどちらが速いか？
多分一般的には実数を引っ張ってくるほうが速い。
「√2000なんて使うのか使わないのか？」と言われても、「あれば使える」としか言いようが無い。
発想が貧困なのでコンスタント化できそうな全ての関数が出てこないがｗｗｗ

TRONはカーネルだからLinuxもアンドロイドのカーネルになるけど
速さではTRONが一番だからユビキタス社会ではTRONの上にさまざまなＯＳが
乗っかる形になる。
ソフト開発者やユーザーの多さからLinuxやアンドロイドはそのまま残した
ほうがいい、日本はロケットも衛星も自前で飛ばせるしＴＲＯＮの開発元
なんだから余計なＯＳをいれず全部国産で開発したほうがよい、それがJAXAの判断。
省エネでリアルタイムでコードも全部わかるＴＲＯＮはこれほど
宇宙開発むけなＯＳはない。

チップは冷却でどこまででもクロックを上げられると言われるが、さて？
通常利用でも窒素冷却程度で6GHzあたりの2倍程度のクロックには堪えたという話も昔の話。
今度は冷却制御で一定温度範囲内を精密に保つロジックの方向なんじゃないの？

実身、仮身 …

トロンの木馬って奴か

「いつもの人」がいるようだな

TRONて、潰されるとか消えるとかいろいろ言われながらも
しぶとく今まで生き残ってるのが凄いな。
よっぽど実用性が高いんだろうな。

実際、末端の小規模組み込み機器を動かすのにはμITRON最強だろうて

チップ装置を燃料供給装置付近に置くと、冷却触媒が循環する上に冷却もできるんだろ？
そもそもそうしているんじゃないの？
そうなるとTHzでもPHzでもお好きなように、と言われかねないなｗｗｗ

分離して冷却する場合は液体窒素あたりか？
排気や触媒消費をどうするのかな？

室温管理だけで20℃くらいで室温で冷却ファンで、とかいう暴挙は止めて欲しいね。
結局.picosecondとか、.femtosecondとかさらに細かい時間指標項目が欲しくなるだけじゃないの？

VC++ではclockのCLOCKS_PER_SEC指定で分解能的にオシレータ依存のクロック表示が一般的らしいね。細かさは謎。
PHPにも一般開示された指標項目でnanosleepはあるな。
普通はクロックカウンタの分解能もカウンタの2進桁数で扱っていそうだな。
最小単位の1カウントアップ時間と、実時間の差の計測と平均化とさらにその誤差の縮小だよな？
結果的に地球上などで強制冷却で試験せざるを得ないような気がするぞ。
「基準となる設定温度を1℃下げるとどの程度時間分解精度が増すのか？」
さらに「その際の温度分解能は？」という話だろ？
これで未来に限界が見えるので、あまり温度を下げたがらないんじゃないの？
しかしK値の分解能も結局無限だろ？

・・・分析も飽きた。早くやって情報開示してよ。
その際のHz数の桁数をどうするのか？なんて話があるけれども。
ウィンテルに無理に気を使わなければ、どこまでも上げればいいという話になるな。

今北ニワカでスマンが
トロンって昔日本がOS開発始めて良い所に行きそうになったら当時独自開発しようとした戦闘機のF-2同様に雨が潰しに掛かりその時は日の目を見なかったけど
今日世界中で日本製のデジカメビデオが広まってるのはとうじのトロンの技術を応用し、ドコの国も真似できないから

との認識でOK？

>>87
間違ってる。

そもそも日本でも本気で普及させようと思ってたのは一部だけだし、
その一部にしても口ばっかで具体的なものは何もできていなかった。
ドタバタしてるうちに他が先を行過ぎて太刀打ちできなくなっただけ。

こういう組み込み分野ではTRONは普及しているが、それも最近は
Linuxやらに押され気味な印象。
ただそれは組み込み分野がPCに近づいてきたのが原因なので、
場所によってはまだ適材適所なものはある。

全然違います。

で、テレメトリデータフォーマットは？
CCSDS互換とか？
日本語訳したの？
開示されていないけれども。

CCSDSにしろ、そもそも文章量が多いので、自動翻訳させないとわずらわしいんじゃないのか？
自動翻訳しても翻訳結果の補正が必要なはずなので句点ごとに分けられ、辞書項目と対比しやすいような翻訳支援ツールが要る。
Googleのツールに翻訳支援とかがあるが、あれは動作が遅いな。
英文120ページ程度で動作がおもいきりもたついてしまう。
原文を分割しないと使えたものじゃない可能性が高い。

結局、なぜ宇宙開発関連の外国語文書を母国語への翻訳し結果を開示しないのか？が気になる。
CCSDSもあくまで桁数指標や項目などを提示するためのフォーマットなので、さっさと開示してフォーマット内容を議論すればよかろう？
そういったことすらしないで指標よりも桁数が足りないなどという愚挙が出たら、やるべきことをサボった弊害であるとしか言いようが無い。

RGB値は通常24bitで各8bitの各10進256に分解できる。
縦×横×高さで同様に各8bit持てば6次元で各256分割になる。
現実的にはまだ縦×横でしか色認識が難しい可能性があり、あくまで5次元かもしれない。
光学望遠鏡で視認できれば、高速通信も期待できる。

各項目を1024bit持った場合のデータ量はどの程度になるだろうか？
時間分解能が稼ぎにくい場合でも、画面分解能は稼げる可能性が高い。

なぜ犬なんだ？と思った俺はいまエアコンのスイッチを入れた

じゃあ、イプシロンでやってる
ノートPCでモバイル管制　みたいなのは、リナックスになってる可能性あるってことか

Guiは必要ないし、安定性と軽さ重視
当然だろ
TRONは家電も多いよな

無償で使ってると宣伝とか入ったりするんでしょ

早く作れよ。搭載できないじゃないか。