2

我正在编写一个程序，它通过光度学检查 FITS 文件并查找 .dat 文件中给出的星星。其中一个步骤是使用 ephem.separation() 计算两个给定恒星之间的距离

它运作良好。但是，有时分离会返回像 1389660529:33:00.8 这样的角度

import ephem
import math

star = ['21:45:15.00', '65:49:24.0']
first_coo = ['21:45:15.00', '65:49:24.0']

check = ephem.FixedBody()
check._ra = ephem.hours(star[0])
check._dec = ephem.degrees(star[1])
check.compute()

# star is a list with coordinates, strings in form %s:%s:%s

first = ephem.FixedBody()
first._ra = ephem.hours(first_coo[0])
first._dec = ephem.degrees(first_coo[1])
first.compute()

sep = math.degrees(float(ephem.separation(check,first)))
print sep

它随机发生。有没有人遇到过这样的行为？

我在 212 个文件中搜索 18 颗星，循环次数为 3816。可能与它有关？

4

1 回答 1

0
更新：我发布了一个新的 PyEphem 3.7.5.2，它修复了这种将角度与自身进行比较的特殊情况。

您的代码示例有两个有趣的功能：首先，它包含一个我起初认为可能是问题背后的小错误；separation()其次，我错了，您的代码是问题所在，因为当被问及位置距自身多远时，您的代码确实暴露了函数中的缺陷！

您自己的代码中的错误是调用compute()并询问.ra并.dec 返回您正在调用的那一刻的坐标系中的那些坐标compute()- 所以您的两个compute()调用返回两个不同坐标系中的坐标，这些坐标系略有不同，所以结果位置无法进行有意义的比较，separation() 因为separation()需要在同一坐标系中的两个坐标。

要解决此问题，请选择一个now时刻作为您的春分时期：

now = ephem.now()
...
check.compute(epoch=now)
...
first.compute(epoch=now)

这将为您提供可以有意义地比较的坐标。

现在，谈谈 PyEphem 本身的问题！

当提供相同位置的两个副本时，separation()它会继续并尝试找到它们之间的距离，最后进行的计算相当于：

acos(sin(angle) ** 2.0 + cos(angle) ** 2.0)

这应该让我们想起标准的欧几里得距离公式，但它acos()周围是 a 而不是 a sqrt()。问题是，虽然理论上括号内的值应该始终是1.0，但 IEEE 浮点数学内部的舍入并不总是产生总和的平方1.0。相反，它有时会产生一个有点高或有点低的值。

当结果略低于1.0时，separation()将返回一个非常小的坐标间隔，即使它们实际上是“相同的坐标”。</p>

当结果超过1.0一点点时，将在我的系统上返回separation()非数字（数字大于，所以当被问到“什么角度返回这个大于一的值？”时没有答案可以返回。</p> nancos()1.0acos()

我在 GitHub 中创建了一个错误报告，并将为下一版本的 PyEphem 修复此问题：

https://github.com/brandon-rhodes/pyephem/issues/31

同时，您的代码将不得不避免调用separation()实际上是相同位置的两个位置——您是否可以使用在and之间进行两次比较的if语句来检测这种情况，而只使用分隔值来代替？==radec0.0

于 2013-11-24T18:12:06.430 回答