3

観測者の緯度/経度の数値はラジアンとして扱われ、文字列値は 10 進度として扱われるという決定がなされたのはなぜですか?

Python で緯度/経度の値を扱うとき、私は通常、float オブジェクトを扱います。星が正しく配置されている場合、そこに 1 つまたは 2 つの int オブジェクトが浮いている可能性がありますが、ほとんどは浮いています。私はいつも次のような単純なコードを書くことになります：

lat = 0.0
lon = 0.0

observer = ephem.Observer()
observer.lat = lat
observer.lon = lon
# etc... etc...

そして、私は火傷します。緯度/経度の値がラジアンではなく 10 進数であるため、火傷を負ってしまいます。自分が何を間違えたのかと頭を悩ませてしまうので、通常は悪いことです。最後に、ラジアンに変換することになります。理論的には、これを実行して正しい結果を得ることができます。

observer = ephem.Observer()
observer.lat = str(lat)
observer.lon = str(lon)

しかし、それも不安定に思えます。私の値はラジアンでなければならないと思っていました! フロートの場合のみ。文字列または浮動小数点オブジェクトを受け入れることは素晴らしいことですが、python 型に基づいて異なる数値型を受け入れることは矛盾しているようです。次のように、両方の代入が同じ数値型を取ることを期待します。

lat = lon = 0.55
observer.lat = lat  # float lat is assumed to be in radians
observer.lon = lon  # float lon is assumed to be in radians

lat = lon = '0.55'
observer.lat = lat  # string lat is assumed to be in radians
observer.lon = lon  # string lon is assumed to be in radians

次に、10 進度 / dms の変換演算子を指定できます。

lat = '25.0'
lon = 25.0
observer.lat = ephem.to_rad(lat)
observer.lon = ephem.to_rad(lon)

次に、to_rad 関数は、10 進度が float または string オブジェクトとして提供されていることを明示的に想定します。この時点で、インターフェイスは一貫しています。私は _libastro.c を簡単に掘り下げて、この質問の核心にある to_angle 関数を調べました。

これを実装しない正当な理由は思いつきません。実際、私はそれを志願します！しかし、これについて大騒ぎする前に、私はlibastro / pyephemの専門家ではないことを知っているので、これが理にかなっていることを確認するためにこの質問を開こうと思いました. これが非常に正当な理由で行われた可能性は十分にあり、私はどうしようもなく混乱しています。

経験豊富なユーザーまたはソフトウェアのコアに精通している方からコメントをいただければ幸いです。

前もって感謝します！

4

1 に答える 1

2

まず、現在のバージョンの PyEphem で度を明示的にラジアンに変換する必要がある場合、degreeラジアンで測定された 1 度である定数を使用できます。したがって、次のように書くことができます。

observer.lat = 33.7 * ephem.degree

アイデアは、読者がこれを「1 度の 33.7 倍」と見なすことを学習するというものでした — のような関数名に関する私の従来の懸念to_rad()は、それがどの単位から変換されているのかが必ずしも明確ではないということです。関数やメソッドを導入する場合、from_degrees()実際には のような名前が望ましいかもしれませんが、上記のように単純に数値を 1 で乗算するよりもコードが明確になるかどうかはわかりませんdegree。

一歩前に戻ります: ラジアンが既定の角度の単位である理由は、理論的な理由によるものではありません。たとえば、ラジアンが数学で角度を測定する「自然な」方法であるという事実や、ラジアンがPyEphem の角度を取り、三角法を行う人々のための Python のsin()ルーチン— しかし、主な理由は、 PyEphem がラッパーであるライブラリによって使用される基本的な単位であるためです。特に C コードで既に使用している可能性がある人にとっては、基になるライブラリのユニットを非表示にして常に各方向に変換を強制するのではなく、単純に公開することが最も明白な動きのように思われました。cos()libastrolibastro

振り返ってみると、角度を出力することで時間 (赤経の場合) または度 (赤緯の場合) を表示するという便利な機能が実行されることは少し不明瞭だったかもしれませんが、一度その決定が行われると、float → str 変換が時間または度に移動したことが分かります。 — 次に、対称性自体により、str の提供は時間または度としても解釈される必要があるため、文字列出力と文字列入力は同等で同じ単位になります。

.latあなたの議論の結果は、後者のステップ - orのような属性に文字列が提供された場合の str → float の自動変換.lon- があまりにも曖昧であり、単純に無効にする必要があるようです。魔法のTypeErrorサイレント変換ではありません。私は実際に同意する傾向がありますが、この時点で変換を無効にしてephem.degree明示的に乗算するように強制するのは遅すぎると思います. 私は PyEphem が、それに対抗するプログラムを書くことに時間を費やしてきた人々のために働き続けてほしいと思っています。

しかし、あなたの主張は良いと思います。私の新しいskyfieldライブラリでは、PyEphem で遭遇した種類の魔法の変換を行う予定はありません。代わりに、ラジアンまたは度が提供されているかどうかにかかわらず、プログラミングが提供しているものを明示し、「ラベルのない」数値を提供することを決して許可しないようにすることを計画しています. 進化するにつれてその構文を検討したい場合は、GitHub でプロジェクトをチェックアウトできます。

https://github.com/brandon-rhodes/python-skyfield

于 2013-04-07T17:08:51.463 に答える