SonotaCo.JP
SonotaCo Network Japan Forum
SonotaCo.JP Forum Index
homeTop Page  FAQFAQ   検索検索   メンバーリストメンバーリスト   ユーザーグループユーザーグループ   登録する登録する 
 プロフィールプロフィール   プライベートメッセージをチェックするプライベートメッセージをチェックする   ログインログイン 

UFOOrbitV2 リリース
ページ移動 前へ  1, 2, 3, ... 11, 12, 13  次へ
 
新しいトピックを投稿   トピックに返信    SonotaCo.JP Forum Index -> UFOCaptute ソフトウェア 談話室
前のトピックを表示 :: 次のトピックを表示  
投稿者 メッセージ
前田



登録日: 2004.09.01
記事: 2754
所在地: Miyazai JAPAN (E131.4, N31.8)

記事日時: Thu Jun 07, 2007 12:53 am    記事の件名: 誤差とは 引用付きで返信

前田です。

SonotaCoさん詳しい回答いつもありがとうございます。

>先ず、どこまでが生データでどこからが計算結果かという境界は実は不明確だと思います。
>誤差を単純計算したものは誤差としての利用を許すが、やや複雑な計算をしたものは誤差とし>ての利用を許さないというのでは基準が不明確です。
>私は、実際の観測誤差との因果関係が明らかであるかないかという点を判断基準にすべきだと>思います。
>と、ここまではよろしいでしょうか。

この入り口のところ奥が深そうですね。始め少し考えると確かに不明瞭なのは
分かるのですが、もっと考えてみたら、やはり、そこが不明瞭ではまずいような気が
してきました。

上の文章で、SonotaCoさんは、”誤差”と”実際の観測誤差”は別のものと考えておられますね。
私も別のものと考えているのですが、多分SonotaCoの考えているもとの違う分類というか、
分け方をしていることが、その後の文章で分かりました。

SonotaCoさんはプログラムを完結させないといけないので、非常に実践的な誤差を
考えておられ、私はもっと教科書的な誤差を想定していました。実践的な誤差を
考えると、確かにその通りですが、最後は統計量として結果を示さないといけない(示して
ほしい)ので、どこかで、教科書的な誤差に乗り換えないといけないと
思います。その乗り換え方の問題のような感じがしています。
誰が読んでも分かるような文章にするととても長くなるので、感覚的な表現で
すみません。

---
QAの問題(かもしれない)と感じた点をもう一つ上げます。
それは、速度の誤差の取り扱いの非対称性のようなものです。
それは、速度の真の値に対して、大きくふれた場合(同じ標準偏差で)は
eが1を大きく越えるので、棄却されますが、小さくふれた場合はeはそこそこ
の値なので、そのままになります。これは、SonotaCoさんの言うところの
明らかにおかしい値を排除するという点からは間違った処理ではないですが、
出てきた結果は取り扱いにくいデータの集まりになります。(と思います)
これは、QAをどの値にするかと言う問題ではないので、各人の判断ではどうしようも
ありません。

これについても、特に解決策を持っているわけではないので、無責任なのですが、
やはり、(教科書的ではありますが)生データの段階で制限をかければよいとしか
いえません。生データの問題については、SonotaCoさんの言われることはある程度
理解したうえのですが。。

まとまりませんが、QAについて言いたいことは大体これで終わりです。
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Thu Jun 07, 2007 12:04 pm    記事の件名: 数が合わない件 引用付きで返信

前田 wrote:
2と3を逆にすると、結果が変わってきます。
(前回のdtのままになっているので)


そもそもこれがバグですね Embarassed 。次版で直します。
で、ほぼ再現しました。

そもそもの
前田 wrote:

2ヶ所だけの同時観測を解析しています。Allpassの場合です。
88caclc, 40metersとタイトルバーに出ました。
88−40*2=8 この8個の計算結果はどうなったのでしょうか。
Quality.logを見てみると42ペアの結果が載っており、レコードリストに載っ
ていない2つはvo too smallなどとなっていました。

の件ですが、こちらでやっても
88calc 40meteors とでました。

88/2 - 40 = 4 ペアの正体ですが
ログを調べると、3つは以下となっていました。

20070509_040323 radiant under horizon
20070512_013444 radiant under horizon
20070523_025033 vo too small

残る1つもログに出ていました。それは単点観測の

20070520_025036 MZ1_K
20070520_025038 kumamoto01
20070520_025043 MZ1_K

に関するものです。なんとこの3つの観測は時刻が近く、
025038 を共通として 025038-025036 と 025038-025043 の2組が同時観測として成立してしまうのです Shocked
UO2では 1つの流星と同時観測が成立するもの、さらにそれらと同時観測が成立するものはすべて1つの流星とみなすという論理が入っており、これによって、この2つの組み合わせは 1つの流星とみなされ ログにも、画面上のリストにも #34として両方出ていますが、meteorのカンウトとしては 1 になりました。
余談ですが、
このような複雑な組み合わせは多点の同時観測では頻繁に発生することです。別の流星と思っていたものが、後から実は同一と分かり、流星番号に欠番が生じることもあります。このような場合にも meteor としてのカウントは正しくなるように論理を入れた記憶があります。 尚、この同一流星の判定は 1/t による選択範囲を定めるものです。

今回のケースのように同じサイトの2つの流星と同一とみなす事態は普通はまず発生しません。今回はdtが大きいことと all pass であることによって 同時流星として判定がゆるくなりすぎてこのうよなことがおこるのだと思います。

もっとも、今回に似たケースで理論的にはMZ1側が雲によって途中が見えない長経路の流星の2つの区間を2クリップ観測するということも考えられます。
このような場合、どちらの組み合わせが本当なのか、はたまた両方とも本当なのかを自動的に判定するのは結構大変です。
ちなみにQAでみると025036との組み合わせは QA=0.71と0.97 で 025043 との組み合わせは QA=0.76 と0.009 で あきからに前者の組み合わせが妥当ということになっているので、 1/t の処理ではうまく絞られると思います。また、後者は地上経路が遠く離れているので、Gmでも除去可能です。

群流星の極大日には 似た流星が短い間隔で多数発生するので、どんなに論理を追加してもこのようなケースの発生の可能性は残ると思います。
一応、プログラムとしてはこの点については現状のままとしたいと思います。



B20070520_025038TMAP.png
 説明:
1つの流星に2つの相手がいます
 ファイルサイズ:  10 KB
 閲覧数:  21898 回

B20070520_025038TMAP.png



B20070520_025038GMAP.png
 説明:
地上経路ではどちらがふさわしいかは(一応?) 一目瞭然です。
 ファイルサイズ:  16.08 KB
 閲覧数:  21898 回

B20070520_025038GMAP.png


トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Thu Jun 07, 2007 4:37 pm    記事の件名: UFOOrbitV2 V2.03 リリース 引用付きで返信

Quality.log に若干の情報を追加し、dt と GDの変更が次回起動時まで有効にならなかったバグを修正した V2.03 をリリースしました。
今回から 出力である U*.csv に UTの日時が入りました。これを読むためには最新のUFORadiantが必要です。
トップに戻る
ユーザーのプロフィールを表示  
上田昌良



登録日: 2005.02.07
記事: 3084
所在地: 大阪府

記事日時: Thu Jun 07, 2007 10:25 pm    記事の件名: Re:UFOOrbitV2 V2.03 リリース 引用付きで返信

UFOOrbitV2 V2.03 リリースありがとうございました。
U*.csv に UTの日時を入れていただき感謝します。

流星の軌道に1個ずつ、UT日付を入れるのはいささか
疲れていましたので、

これは、特に急ぎませんが、U*.csv ファイル中で、
e>1.0のときにp(周期)が0と表示されています。
e>1.0のときには、p(周期)のセルは「空白」にしていただき
たいですね、p=0年と思う人はいないと思いますが、
念のため、
トップに戻る
ユーザーのプロフィールを表示  
前田



登録日: 2004.09.01
記事: 2754
所在地: Miyazai JAPAN (E131.4, N31.8)

記事日時: Fri Jun 08, 2007 7:51 am    記事の件名: ありがとうございます 引用付きで返信

前田です。
LOGの解釈の仕方ありがとうございます。3つの流星で2組の流星が検出されていたのは
気が付いていたのですが、(こちらではdtがおおきいので、頻繁に生じます)これらを
1つの流星に数えていたことに気が付きませんでした。
V203まだ試していませんが、同時流星数のカウント情報などがついていたらいいなと
思っています。

>もっとも、今回に似たケースで理論的にはMZ1側が雲によって途中が見えない長経路の
>流星の2つの区間を2クリップ観測するということも考えられます

1流星を2つに分割することはUFOAnalyzeで結構あります。(視野内にTVアンテナなど
があるので)これをチェックの時に見落とすと本当は1つの流星から2つの軌道がでてしまう
ので、注意しています。

---

自分でチェックしていませんが、
流星経路が遠くに出てしまう問題ですが、高度は高くなっているのですか。
そうでなければ、観測視野からありえない場所に出現したことを判断できませんか。

---
同時流星の検出でもう一つ気になることがあります。
ときどき、同じ地点の同じ観測どおしを同時と判定して、対地計算をはじめ、
観測地間の距離が近すぎるという条件ではじかれていることがあります。
実害はないのですが、すこし、気になります。
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Fri Jun 08, 2007 8:00 am    記事の件名: Re:UFOOrbitV2 V2.03 リリース 引用付きで返信

上田昌良 wrote:
UFOOrbitV2 V2.03 リリースありがとうございました。
U*.csv に UTの日時を入れていただき感謝します。

流星の軌道に1個ずつ、UT日付を入れるのはいささか
疲れていましたので、

どうも遅くなってすませんでした。UFORadiant側での対応をしているうちに他の問題の可能性が浮上して公開が遅れてしまいました。
上田昌良 wrote:

これは、特に急ぎませんが、U*.csv ファイル中で、
e>1.0のときにp(周期)が0と表示されています。
e>1.0のときには、p(周期)のセルは「空白」にしていただき
たいですね、p=0年と思う人はいないと思いますが、
念のため、

うーん、空白はいろいろ問題を招きかねないので、これはやらないと思います。
無い値をどう表現するかは常に問題なのですが......

別途、現在の改良メモをまとめました。
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Fri Jun 08, 2007 10:07 am    記事の件名: どこかに数億円のソフト開発予算ないでしょうか 引用付きで返信

前田 wrote:
前自分でチェックしていませんが、
流星経路が遠くに出てしまう問題ですが、高度は高くなっているのですか。
そうでなければ、観測視野からありえない場所に出現したことを判断できませんか。

もちろん高度は大きくなっていて、全て視野内に入っています。
前の例はall pass で極端でしたが、たとえばH1 < 180, H2 < 150という条件で
絞ると以下のように、超遠方のものはなくなりますが、これは程度問題です。
これでも個々を見ていくと不自然でありえないものが数多く含まれています。
高度でどんどん絞っていけば変なものはもちろんどんどん減っていきますが、
他の正常なものの排除が増加し、それこそ結果に偏りを生じてしまいます。
経験では、高度で絞るよりはeで絞るほうがより的確です。
これは e が1を超える流星が本当に存在するとしても、その数は極めて小さい
ことが原因していて、平均的な精度を求めるのならeは良い尺度となる
ということだと思います。

なんか、遠い昔にもこれと似た話をした記憶が蘇ってきました。
要は目的次第だということだと思うのですが.....

もちろん、速度や離心率の統計処理をする場合にはQAでなく、QcやEdなどの
結果に対する除去率の偏りが小さいと思われる尺度のみによる絞りこみ
が妥当なことは前田さんのおっしゃるとおりだと思っています。
しかしその場合には別の手段で誤差が極めて大きいものを排除する必要があります。
問題は、その良い方法が今はないことで、
たぶん、速度の誤差を今は決定できていないことが原因ことなのです。

繰り返しになりますが、
おそらくは前田さんのリクエストを満たすシステムも技術的には構築可能です。
輻射点計算と速度計算を分離して、輻射点計算結果をフィードバックして、
フィールド毎速度測定誤差を出し、それを共分散行列を使って誤差伝播すれば
よいかと思います。
これは言うのは簡単で実現に対する技術的な問題点も少ないですが、
膨大な時間が必要で今私にはできないです。
我々には現実に大量のデータがあります。これをできる範囲でベストと思われる
方法で処理し、活かしていこうと思っています。

前田 wrote:

ときどき、同じ地点の同じ観測どおしを同時と判定して、対地計算をはじめ、
観測地間の距離が近すぎるという条件ではじかれていることがあります。
実害はないのですが、すこし、気になります。


これは現象が想像できません。
"観測地間の距離が近すぎるという条件はじかれている"
これは具体的にはどういう状況になっているのでしょうか。



B20060102_GMAP.png
 説明:
地上経路がおかしいものが多数含まれています
 ファイルサイズ:  69.09 KB
 閲覧数:  21831 回

B20060102_GMAP.png


トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Fri Jun 08, 2007 2:26 pm    記事の件名: 引用付きで返信

蛇足ですが、
取り除くべき変なもの には 今回あったような 流星の取り違いや、片方がノイズや鳥の場合とか、分析直線が光芒の進行方向と全然一致していない時とか、とても誤差と呼べない「あきからな間違い」を含んでいます。
特に地上経路が離れている場合には、要注意です。
2つの画像を人間が目で確認して、地上経路もよく一致している場合にはこれらは殆ど発生しませんが、多数の方が自動でやられている現状では、相当頻繁に発生します。

従って、これらを自動的にできるだけ完全に排除することは第一歩というか必須命題なわけです。先の例で、3つの観測のうちもし最初の観測が無かったとしたら、完全に誤ったものが結果に含まれしまうかもしれず、誤差の議論以前になんとかしないといけないわけです。
で、dGPとかGmとか色々なものを発明して色々試した結果、取り扱いが簡単なものとしてQAが生まれているわけです。
トップに戻る
ユーザーのプロフィールを表示  
前田



登録日: 2004.09.01
記事: 2754
所在地: Miyazai JAPAN (E131.4, N31.8)

記事日時: Mon Jun 18, 2007 12:08 am    記事の件名: よみ落としていました。 引用付きで返信

前田です。
最近書き込みが多くてよみ落としていました。すみません。

>高度でどんどん絞っていけば変なものはもちろんどんどん減っていきますが、
>他の正常なものの排除が増加し、それこそ結果に偏りを生じてしまいます。
>経験では、高度で絞るよりはeで絞るほうがより的確です。

そうですか。高度で縛るのは確かによくないでしょうね。

>おそらくは前田さんのリクエストを満たすシステムも技術的には構築可能です。
>輻射点計算と速度計算を分離して、輻射点計算結果をフィードバックして、
>フィールド毎速度測定誤差を出し、それを共分散行列を使って誤差伝播すれば
>よいかと思います。

そんな、高度なことはことはリクエストしているつもりはないのですが、、。
誤差を出すためにフィードバックして計算するのは、本末転倒な感じです。

>蛇足ですが、
>取り除くべき変なもの には 今回あったような 流星の取り違いや、片方がノイズや
>鳥の場合とか、分析直線が光芒の進行方向と全然一致していない時とか、とても誤差
>と呼べない「あきからな間違い」を含んでいます。

蛇足と書かれていますが、ここが今回の一連の話の2番目に重要なところだと
思っています。普通の誤差は正規分布をしますが、この手の間違いは正規分布
しませんから、狭い意味では誤差と読ばないものですね。(だと個人的に思ってます)
これを除くのも難しいですが、そのためにeを使うのは、経験的にはよいのでしょうね。

>たぶん、速度の誤差を今は決定できていないことが原因ことなのです。

最初にSonotaCoさんが書かれましたが、やはり、ここが気になります。
誤差は、a±δa のδaの方なので、aが決まった時に同時に決めないと行けない量
(通常は標準偏差ですね)ではないかと思います。ソフトの詳細は分かりませんが、
何かえいと決めることはでき無いでしょうか。共分散まで使わずにただの分散の伝搬
程度でも、おおよその見積もりは可能なので、表示されると目安になると言った考えです。


>同時流星の検出でもう一つ気になることがあります。
>ときどき、同じ地点の同じ観測どおしを同時と判定して、対地計算をはじめ、
>観測地間の距離が近すぎるという条件ではじかれていることがあります。

観測地間の距離が近すぎてはじかれた例は見つかりませんでしたが、以下のようなものです。
同じ観測地点間で同時流星を計算しているように見えます。(これは、Orbit 201です)

[20061201_035506 kumamoto01 -- kumamoto01] dt=+9.0
[kumamoto01] drop=1.0 inout=0.8 tme=1.0 leap=1.0 --> 0.797 evro=-71.9... radiant under horizon
[kumamoto01] drop=1.0 inout=1.0 tme=1.0 leap=1.0 --> 0.996 vo=1.00 e=1.00 ex=0.98 --> 0.979
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
前田



登録日: 2004.09.01
記事: 2754
所在地: Miyazai JAPAN (E131.4, N31.8)

記事日時: Mon Jun 18, 2007 12:24 am    記事の件名: 表示のおかしい所 引用付きで返信

前田です。
UFOOrbit203で、Radiantタブでdecを0以外の値にした時に、マウスの位置の赤緯などの値が、おかしい感じです。decが0のままの値のようです。
再現できますでしょうか。

---
Mainタブのどこかに、他のUFOシリーズのソフトのようにバージョンを表示して欲しいです。
トップに戻る
ユーザーのプロフィールを表示   投稿者のウェブサイトに移動
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Mon Jun 18, 2007 8:40 am    記事の件名: Re: 表示のおかしい所 引用付きで返信

前田 wrote:

UFOOrbit203で、Radiantタブでdecを0以外の値にした時に、マウスの位置の赤緯などの値が、おかしい感じです。decが0のままの値のようです。
再現できますでしょうか。。

あ、これは私も先日気が付き修正版の用意をした所でした Embarassed
今日公開します。
前田 wrote:

Mainタブのどこかに、他のUFOシリーズのソフトのようにバージョンを表示して欲しいです。

シートの過密を恐れて、起動直後のみ、タイトルバーに出すようにしたのですが、
結局、Mainシートはガラガラでしたね Wink 。そうしましょう。
前田 wrote:

観測地間の距離が近すぎてはじかれた例は見つかりませんでしたが、以下のようなものです。
同じ観測地点間で同時流星を計算しているように見えます。(これは、Orbit 201です)

事態が想像できました。これは通常のことだと思います。このケースでは
GDを0に設定しているのではないでしょうか。GDでの判定があるので、同じ名前の観測点の事前排除というのは特にやっていません。GDは通常は10程度に設定しておいてください。

さて、
誤解があるようなので、説明しておきます。
1つの観測の速度誤差を出すのに 進入方向のみを用いた同時観測結果の輻射点位置を使うのは本末転倒ではありません。そうしないと各時刻の対象位置が決まらないので、当然のことです。

単純な方法での速度誤差の算出はこれまでにも試してきたのですが、
実際のデータを扱うと、ビデオ映像の位置と明度に関する量子化ノイズの影響を痛感します。640x480の8ビットというのは、その中でどんなにもがいても無意味と思えるほど厳しいのです。特に速度は微分なわけで、とてもデリケートです。

でも、速度誤差の算出についても、実用化のメドが次第にできてきています Cool
今のフレームワークというか、交換データの大幅な追加が必要で、データ量の問題も出るので、オープンなシステムとしては色々解決すべき事柄があります。
その前に鳥や昆虫をもう少し排除する必要もあります。
あとは、時間とやる気の問題なのですが......
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Sat Sep 29, 2007 2:35 pm    記事の件名: UFOOrbitV2 V2.05 リリース 引用付きで返信

海外からの要望で、Metrecの出力をUFOOrbitへ取り込み可能なようにしたいと思っています。
変換には別途専用ツールを作り、R80フォーマットという新形式とします。
UFOOrbitV2 V2.05 はそれを受け取るための機能追加です。
他は細かいバグの修正で、現状でご不便のない方は必ずしもV2.05にする必要はありません。

あわせて、オーストラリア用の背景地図を公開しました。
トップに戻る
ユーザーのプロフィールを表示  
さぎたりうす



登録日: 2004.08.09
記事: 4391
所在地: 大阪府大阪市東淀川区

記事日時: Sat Sep 29, 2007 5:30 pm    記事の件名: Re: UFOOrbitV2 V2.05 リリース 引用付きで返信

SonotaCo wrote:
海外からの要望で、Metrecの出力をUFOOrbitへ取り込み可能なようにしたいと思っています。
変換には別途専用ツールを作り、R80フォーマットという新形式とします。
UFOOrbitV2 V2.05 はそれを受け取るための機能追加です。
他は細かいバグの修正で、現状でご不便のない方は必ずしもV2.05にする必要はありません。

あわせて、オーストラリア用の背景地図を公開しました。


当初バージョンからだと思うのですが、
Orbitウインドでsclをうっかり0にするとアプリケーションがフリーズしてしまいます。
0の入力を受け付けないようにするか、アラートを出すようにした方が良いと思います。
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Sat Sep 29, 2007 6:20 pm    記事の件名: Re: UFOOrbitV2 V2.05 リリース 引用付きで返信

さぎたりうす wrote:
当初バージョンからだと思うのですが、
Orbitウインドでsclをうっかり0にするとアプリケーションがフリーズしてしまいます。
0の入力を受け付けないようにするか、アラートを出すようにした方が良いと思います。

V2.00 からの潜在バグでした。スピンボタンでは1以下にならないので、見逃されていました。
お知らせありがとうございます。凄いのが見つかりますね Embarassed
次版で直しますが、当面、緊急の改版はしないつもりです。
トップに戻る
ユーザーのプロフィールを表示  
SonotaCo
Site Admin


登録日: 2004.08.07
記事: 12653
所在地: 139.67E 35.65N

記事日時: Wed Oct 24, 2007 6:24 pm    記事の件名: UFOOrbitV2 V2.06リリース 引用付きで返信

以下を修正した V2.06 をリリースしました。

細かいバグ対応なので、ご不便のない方は特に更新する必要はありません。
・Orbitシートでscl に 0 を設定するとハングする問題点を修正した。
・single site モードでリスト上で1つが選択されているとトレイルマップで始点と0.0を結ぶ余計な線が表示される問題を修正した。
・経度が負(西経)の場合に地上経路が表示されないバグを修正した。
トップに戻る
ユーザーのプロフィールを表示  
特定期間内の記事を表示:   
新しいトピックを投稿   トピックに返信    SonotaCo.JP Forum Index -> UFOCaptute ソフトウェア 談話室 All times are GMT + 9 Hours
ページ移動 前へ  1, 2, 3, ... 11, 12, 13  次へ
Page 2 of 13

 
移動先:  
新規投稿: 不可
返信投稿: 不可
記事編集: 不可
記事削除: 不可
投票参加: 不可
このフォーラムで添付ファイルを投稿 できません
このフォーラムでファイルをダウンロード できます


Powered by phpBB © 2001, 2005 phpBB Group
Copyright ©2004 SonotaCo Network. All Rights Reserved.