types - pyephem - 观察者纬度/经度类型

Question

为什么决定将观察者的纬度/经度数值视为弧度，而将字符串值视为十进制度数？

在 Python 中处理纬度/经度值时，我通常会处理 float 对象。如果星星排列正确，可能会有一个或两个 int 对象漂浮在那里，但大部分都是漂浮的。我总是天真地写一些这样的代码:

lat = 0.0
lon = 0.0

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

然后，我被烧伤了。我被烫伤了，因为我的纬度/经度值是十进制度数，而不是弧度。这通常很糟糕，因为我最终会挠头想知道我做错了什么。最后，我最终转换为弧度。现在理论上，我可以这样做以获得正确的结果:

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

但这似乎也很奇怪，我认为我的值必须以弧度为单位!哦等等，只有当它是一个 float 时。我知道接受字符串或浮点对象很好，但接受基于 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

然后可以为十进制度/dms 提供转换运算符:

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

然后 to_rad 函数将明确假定十进制度数作为 float 或字符串对象提供。此时，接口(interface)将是一致的。我非常简要地浏览了 _libastro.c 并研究了 to_angle 函数，这是这个问题的核心。

我想不出不实现它的充分理由。事实上，我会自愿去做!但在我开始讨论这个问题之前，我知道我不是 libastro/pyephem 专家，所以我想打开这个问题以确保这是有道理的。这样做完全有可能是出于非常充分的理由，我只是感到非常困惑。

如果有经验的用户或熟悉软件核心的人可以发表评论，我将不胜感激。

提前致谢!

Answer 1

首先:当您需要在当前版本的 PyEphem 中将度数显式转换为弧度时，您可以使用 degree 常数，它是以弧度测量的度数。所以你可以这样写:

observer.lat = 33.7 * ephem.degree

当时的想法是，读者会学会将其视为“33.7 乘以 1 度”——我对像 to_rad() 这样的函数名称的传统担心是，它不一定清楚是什么单位它正在转换 from. 如果要引入一个函数或方法，那么像 from_degrees() 这样的名称实际上可能更可取——但我不确定我自己会不会发现代码比简单地将数字乘以一个 degree 更清晰，如上图所示。

更进一步:弧度是默认角度测量的原因不是出于任何理论原因——例如弧度是数学中测量角度的“自然”方式，或者它们是Python 的 sin() 和 cos() 例程期望使用 PyEphem 角度和三角函数的人使用的单位 — 但主要是因为这是 使用的基础单位>libastro 库，其中 PyEphem 是一个包装器。这似乎是最明显的举措，特别是对于那些可能已经在他们的 C 代码中使用过 libastro 的人来说，简单地公开底层库的单元而不是隐藏它们并始终在每个方向强制转换。

回想起来，打印角度可以方便地显示小时数(赤经)或度数(赤纬)，这可能有点模糊，但是一旦做出决定—— float → str 转换移动到小时或度数——然后对称性本身决定提供一个 str 也应该被解释为小时或度数，这样字符串输出和字符串输入将是等效的，并且使用相同的单位。

您的论点的结果似乎是后一步 — 如果为 .lat 或 .lon 等属性提供了字符串，则自动进行 str → float 转换— 太晦涩了，应该简单地禁用，因为在传统上应该是数字的地方提供一个字符串会导致 Python 中的 TypeError，而不是神奇的静默转换。我实际上倾向于同意，但我认为现在禁用转换并强制人们显式地乘以 ephem.degree 为时已晚，因为那样会破坏太多现有代码。我希望 PyEphem 继续为那些投入时间编写程序的人服务。

但我认为你的观点很好，在我的新 skyfield 库中，我不打算进行你在 PyEphem 中遇到的任何类型的魔法转换。相反，无论提供弧度还是度数，我都计划让程序明确说明他们提供的内容，并且永远不允许他们提供“未标记”的数字。如果你想在它的发展过程中权衡它的语法，你可以在 GitHub 上查看这个项目:

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