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

Question

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

在 Python 中处理 lat / lon 值时，我通常处理浮点对象。如果星星对齐正确，可能会有一个或两个 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)

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

然后可以为十进制度/分度数提供转换运算符：

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

然后 to_rad 函数将明确假定十进制度数作为浮点或字符串对象提供。在这一点上，接口将是一致的。我非常简要地挖掘了 _libastro.c 并研究了 to_angle 函数，它是这个问题的核心。

我想不出一个很好的理由不执行此操作。事实上，我会自愿去做！但是在我对此进行讨论之前，我知道我不是 libastro / pyephem 专家，所以我想打开这个问题以确保这是有道理的。这样做完全有可能是有充分理由的，我只是感到非常困惑。

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

提前谢谢你！

Answer 1

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

observer.lat = 33.7 * ephem.degree

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

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

回想起来可能有点模糊，打印角度可以方便地显示小时（对于 RA）或度数（对于偏角），但是一旦做出决定 - 浮点 → str 转换移动到小时或度数 - 然后对称性本身决定提供 str 也应解释为小时或度数，以便字符串输出和字符串输入等效且单位相同。

您的论点的结果似乎是后一步 - 如果为 .lat 或 .lon 之类的属性提供字符串，则自动 str → float 转换 - 太模糊了，应该简单地禁用，因为提供传统上应该是数字的字符串在 Python 中会导致 TypeError，而不是神奇的静默转换。我实际上倾向于同意，但我认为此时禁用转换并强制人们明确乘以ephem.degree 为时已晚，因为这会破坏很多现有代码。我希望 PyEphem 继续为那些投入时间编写针对它的程序的人工作。

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

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