search

rstub / swephR

High Precision Ephemeris
https://rstub.github.io/swephR/
10 stars 1 forks source link

Cannot get swephR to use Swiss Ephemeris instead of Moshier #61

Closed batuozdemir closed 2 years ago

batuozdemir commented 2 years ago

Hi, Posted the same issue on swephRdata github but got no answers.

I have the swephRdata package installed, and when I set iflag <- SE$FLG_SWIEPH + SE$FLG_SPEED it still uses the Moshier ephemeris.

I tried using the swe_set_ephe_path function swe_set_ephe_path(path = "/Users/user/Library/R/4.0/library/swephRdata/ephemeris") but no luck.

Could you help me with this please? Thanks

vreijs commented 2 years ago

Hello Explosive, I have been away an still busy relocating houses (over the coming months). But I will try to see if I can look in to this. I have the feel that you use the right commands, as long as you have indeed the swephRdata in the directory you mention. Just to be sure, do you see the *.se1 files in /Users/user/Library/R/4.0/library/swephRdata/ephemeris

batuozdemir commented 2 years ago

Hi, thanks very much for your reply. Feels weird being called explosive, very very old nickname and hadn't realized I had it here on github haha.

Yes, I do see the .se1 files on this directory.

I'm currently moving houses too, I know what a pain it is. Best of luck.

rstub commented 2 years ago

Can you provide us with a reproducible example, preferably using the reprex package. On my system I get the following when I also include the session info:

library(swephR)

year <- 2000
month <- 1
day <- 1
hour <- 12
jdut <- swe_julday(year, month, day, hour, SE$GREG_CAL)
jdut
#> [1] 2451545

ipl <- SE$SUN
iflag <- SE$FLG_MOSEPH + SE$FLG_SPEED
result <- swe_calc_ut(jdut, ipl, iflag)
result
#> $return
#> [1] 260
#> 
#> $xx
#> [1]  2.803689e+02  2.323265e-04  9.833276e-01  1.019432e+00 -8.922802e-07
#> [6] -7.339410e-06
#> 
#> $serr
#> [1] ""

Created on 2021-11-16 by the reprex package (v2.0.1)

Session info ``` r sessioninfo::session_info() #> ─ Session info ─────────────────────────────────────────────────────────────── #> setting value #> version R version 4.1.2 (2021-11-01) #> os Debian GNU/Linux 11 (bullseye) #> system x86_64, linux-gnu #> ui X11 #> language en_US:en #> collate en_US.UTF-8 #> ctype en_US.UTF-8 #> tz Europe/Berlin #> date 2021-11-16 #> #> ─ Packages ─────────────────────────────────────────────────────────────────── #> package * version date lib source #> backports 1.2.1 2020-12-09 [2] CRAN (R 4.0.3) #> cli 3.1.0 2021-10-27 [1] CRAN (R 4.1.2) #> crayon 1.4.0 2021-01-30 [2] CRAN (R 4.0.3) #> digest 0.6.27 2020-10-24 [2] CRAN (R 4.0.3) #> ellipsis 0.3.2 2021-04-29 [1] CRAN (R 4.1.2) #> evaluate 0.14 2019-05-28 [2] CRAN (R 4.0.0) #> fastmap 1.1.0 2021-01-25 [2] CRAN (R 4.0.3) #> fs 1.5.0 2020-07-31 [1] CRAN (R 4.1.2) #> glue 1.4.2 2020-08-27 [2] CRAN (R 4.0.2) #> highr 0.8 2019-03-20 [2] CRAN (R 4.0.0) #> htmltools 0.5.2 2021-08-25 [1] CRAN (R 4.1.2) #> knitr 1.31 2021-01-27 [2] CRAN (R 4.0.3) #> lifecycle 1.0.1 2021-09-24 [1] CRAN (R 4.1.2) #> magrittr 2.0.1 2020-11-17 [2] CRAN (R 4.0.3) #> pillar 1.4.7 2020-11-20 [2] CRAN (R 4.0.3) #> pkgconfig 2.0.3 2019-09-22 [2] CRAN (R 4.0.0) #> purrr 0.3.4 2020-04-17 [2] CRAN (R 4.0.0) #> R.cache 0.15.0 2021-04-30 [1] CRAN (R 4.1.2) #> R.methodsS3 1.8.1 2020-08-26 [2] CRAN (R 4.0.2) #> R.oo 1.24.0 2020-08-26 [2] CRAN (R 4.0.2) #> R.utils 2.11.0 2021-09-26 [1] CRAN (R 4.1.2) #> Rcpp 1.0.6 2021-01-15 [2] CRAN (R 4.0.3) #> reprex 2.0.1 2021-08-05 [1] CRAN (R 4.1.2) #> rlang 0.4.10 2020-12-30 [2] CRAN (R 4.0.3) #> rmarkdown 2.11 2021-09-14 [1] CRAN (R 4.1.2) #> rstudioapi 0.13 2020-11-12 [2] CRAN (R 4.0.3) #> sessioninfo 1.1.1 2018-11-05 [2] CRAN (R 4.0.0) #> stringi 1.5.3 2020-09-09 [2] CRAN (R 4.0.2) #> stringr 1.4.0 2019-02-10 [2] CRAN (R 4.0.0) #> styler 1.6.2 2021-09-23 [1] CRAN (R 4.1.2) #> swephR * 0.3.0 2019-08-28 [1] CRAN (R 4.0.0) #> tibble 3.0.6 2021-01-29 [2] CRAN (R 4.0.3) #> vctrs 0.3.6 2020-12-17 [2] CRAN (R 4.0.3) #> withr 2.4.1 2021-01-26 [2] CRAN (R 4.0.3) #> xfun 0.28 2021-11-04 [1] CRAN (R 4.1.2) #> yaml 2.2.1 2020-02-01 [2] CRAN (R 4.0.0) #> #> [1] /usr/local/lib/R/site-library #> [2] /usr/lib/R/site-library #> [3] /usr/lib/R/library ```
batuozdemir commented 2 years ago

Here is the reprex code:

library(swephR)
library(swephRdata)

SE_EPHE_PATH <- "/Library/Frameworks/R.framework/Versions/4.1/Resources/library/swephRdata/ephemeris"
swe_set_ephe_path(SE_EPHE_PATH)

year <- 2000
month <- 1
day <- 1
hour <- 12
julday <- swe_julday(year,month,day,hour,SE$GREG_CAL)

iflag <- SE$FLG_SWIEPH
iflag_moseph <- SE$FLG_MOSEPH

swe_calc_ut(julday, SE$SUN, iflag)
#> $return
#> [1] 2
#> 
#> $xx
#> [1] 2.803689e+02 2.274112e-04 9.833276e-01 0.000000e+00 0.000000e+00
#> [6] 0.000000e+00
#> 
#> $serr
#> [1] ""
swe_calc_ut(julday, SE$SUN, iflag_moseph)
#> $return
#> [1] 4
#> 
#> $xx
#> [1] 2.803689e+02 2.323265e-04 9.833276e-01 0.000000e+00 0.000000e+00
#> [6] 0.000000e+00
#> 
#> $serr
#> [1] ""

# swe_calc_ut(julday, SE$MOON, iflag)
# swe_calc_ut(julday, SE$MOON, iflag_moseph)

Created on 2021-11-16 by the reprex package (v2.0.1)

Session info:

─ Session info  🅾️  🤭  🐛   ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 hash: O button (blood type), face with hand over mouth, bug

 setting  value
 version  R version 4.1.2 (2021-11-01)
 os       macOS High Sierra 10.13.6
 system   x86_64, darwin17.0
 ui       RStudio
 language (EN)
 collate  en_US.UTF-8
 ctype    en_US.UTF-8
 tz       Europe/Istanbul
 date     2021-11-16
 rstudio  1.2.1335 (desktop)
 pandoc   2.3.1 @ /Applications/RStudio.app/Contents/MacOS/pandoc/ (via rmarkdown)

─ Packages ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 package     * version date (UTC) lib source
 cachem        1.0.6   2021-08-19 [1] CRAN (R 4.1.0)
 callr         3.7.0   2021-04-20 [1] CRAN (R 4.1.0)
 cli           3.1.0   2021-10-27 [1] CRAN (R 4.1.0)
 clipr         0.7.1   2020-10-08 [1] CRAN (R 4.1.0)
 crayon        1.4.2   2021-10-29 [1] CRAN (R 4.1.0)
 desc          1.4.0   2021-09-28 [1] CRAN (R 4.1.0)
 devtools    * 2.4.2   2021-06-07 [1] CRAN (R 4.1.0)
 digest        0.6.28  2021-09-23 [1] CRAN (R 4.1.0)
 ellipsis      0.3.2   2021-04-29 [1] CRAN (R 4.1.0)
 evaluate      0.14    2019-05-28 [1] CRAN (R 4.1.0)
 fansi         0.5.0   2021-05-25 [1] CRAN (R 4.1.0)
 fastmap       1.1.0   2021-01-25 [1] CRAN (R 4.1.0)
 fs            1.5.0   2020-07-31 [1] CRAN (R 4.1.0)
 glue          1.5.0   2021-11-07 [1] CRAN (R 4.1.0)
 highr         0.9     2021-04-16 [1] CRAN (R 4.1.0)
 htmltools     0.5.2   2021-08-25 [1] CRAN (R 4.1.0)
 knitr         1.36    2021-09-29 [1] CRAN (R 4.1.0)
 lifecycle     1.0.1   2021-09-24 [1] CRAN (R 4.1.0)
 magrittr      2.0.1   2020-11-17 [1] CRAN (R 4.1.0)
 memoise       2.0.0   2021-01-26 [1] CRAN (R 4.1.0)
 pillar        1.6.4   2021-10-18 [1] CRAN (R 4.1.0)
 pkgbuild      1.2.0   2020-12-15 [1] CRAN (R 4.1.0)
 pkgconfig     2.0.3   2019-09-22 [1] CRAN (R 4.1.0)
 pkgload       1.2.3   2021-10-13 [1] CRAN (R 4.1.0)
 prettyunits   1.1.1   2020-01-24 [1] CRAN (R 4.1.0)
 processx      3.5.2   2021-04-30 [1] CRAN (R 4.1.0)
 ps            1.6.0   2021-02-28 [1] CRAN (R 4.1.0)
 purrr         0.3.4   2020-04-17 [1] CRAN (R 4.1.0)
 R6            2.5.1   2021-08-19 [1] CRAN (R 4.1.0)
 Rcpp          1.0.7   2021-07-07 [1] CRAN (R 4.1.0)
 remotes       2.4.1   2021-09-29 [1] CRAN (R 4.1.0)
 reprex      * 2.0.1   2021-08-05 [1] CRAN (R 4.1.0)
 rlang         0.4.12  2021-10-18 [1] CRAN (R 4.1.0)
 rmarkdown     2.11    2021-09-14 [1] CRAN (R 4.1.0)
 rprojroot     2.0.2   2020-11-15 [1] CRAN (R 4.1.0)
 rstudioapi    0.13    2020-11-12 [1] CRAN (R 4.1.0)
 sessioninfo   1.2.1   2021-11-02 [1] CRAN (R 4.1.0)
 swephR      * 0.3.0   2019-08-28 [1] CRAN (R 4.1.0)
 swephRdata  * 0.0.1   2021-11-16 [1] local
 testthat      3.1.0   2021-10-04 [1] CRAN (R 4.1.0)
 tibble        3.1.6   2021-11-07 [1] CRAN (R 4.1.0)
 usethis     * 2.1.3   2021-10-27 [1] CRAN (R 4.1.0)
 utf8          1.2.2   2021-07-24 [1] CRAN (R 4.1.0)
 vctrs         0.3.8   2021-04-29 [1] CRAN (R 4.1.0)
 withr         2.4.2   2021-04-18 [1] CRAN (R 4.1.0)
 xfun          0.28    2021-11-04 [1] CRAN (R 4.1.0)
 yaml          2.2.1   2020-02-01 [1] CRAN (R 4.1.0)

 [1] /Library/Frameworks/R.framework/Versions/4.1/Resources/library

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
rstub commented 2 years ago

Thanks for that. To me this looks as if the Swiss Ephemeris is actually used:

Overall this looks to me as if the SE is being used here. BTW, that should also be the case w/o the explicit library(swephRdata) and swe_set_ephe_path().

batuozdemir commented 2 years ago

Thanks @rstub,

I realize the values for latitude and distance are slightly different, but the value for longitude are the same to the dot. And longitude, or right ascension, is the primary variable to compute planet positions in astrology.

I used online methods to compute the sun's position for the date in the example above and it should be 280.22, but as you can see it computes ~280.37. I really need the precision of Swiss Ephemeris here, Moshier computations can be off up to 1 degrees. So maybe the code thinks it is using Swiss Ephemeris but it is not really.

vreijs commented 2 years ago

I am glad it works as expected! Thanks Ralf for progressing this.

On Tue, 16 Nov 2021 at 11:35, Ralf Stubner @.***> wrote:

Thanks for that. To me this looks as if the Swiss Ephemeris is actually used:

  • The return code $return is the effective iflag that is being used during the computation. If the SE where not available, this would be changed. But here you get back the the value you send in. So everything is fine.
  • The computed values in $xx are slightly different. This difference is really small, but then the Moshier ephemeris is pretty good. One has to go (far) into the future or past to see larger differences.
  • There are no error messages in $err .

Overall this looks to me as if the SE is being used here. BTW, that should also be the case w/o the explicit library(swephRdata) and swe_set_ephe_path().

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/61#issuecomment-970137787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFTBWTYI4RFHTFZ3SNLUMIXVTANCNFSM5HYFJK3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

batuozdemir commented 2 years ago

@vreijs it doesn't 😅. If you read my last comment you can see it seems to be using the correct ephemeris but calculating incorrect outputs.

vreijs commented 2 years ago

Can your provide the results of SwephR and the computer program you compare it with. Include the date, time, timezone, geo longitude, geo latitude.

My experience is that even Mosphier is quite accurate from -3000 (certainly within 1 degree) I compare with SkyMap or JPL of NASA or Stellarium (although that is/was less accurate).

I have also implemented Swiss Ephemeris in Excel, so I can thus also check with that.

All the best,

Victor

On Tue, 16 Nov 2021 at 12:13, Batu @.***> wrote:

@vreijs https://github.com/vreijs it doesn't 😅. If you read my last comment you can see it seems to be using the correct ephemeris but calculating incorrect outputs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/61#issuecomment-970167787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFR6RSU753LHJ3DUSPLUMI4FLANCNFSM5HYFJK3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

batuozdemir commented 2 years ago

@vreijs It really doesn't matter what I compare it with because the R code computing the same output to six significant digits for both Moshier ephemeris and (supposedly) Swiss ephemeris, that should be enough to prove there is something wrong here.

But to answer your question, I compared the result to multiple astrology websites and software (e.g. astro-seek.com). In the example above I used 01/01/2000 12:00:00 UTC. The swephR package computes sun's longitude as 2.803689e+02=~280.37 degrees, other software I used compute it as 10.22 degrees Capricorn (=280.22 degrees).

I am not a programmer and just attempting something here with your package, so I don't even know how to use other fancy astronomy data calculators, if there are any.

vreijs commented 2 years ago

Can you name the computer program that provides 10.22 degrees Capricorn (=280.22 degrees? Or is this astro-seek? One needs to be sure which ephemeris the program uses. Swiss Ephemeris uses quite a recent one DE431. Do you have the help page that provides something about the underlying formulas/ephemeris/etc. used?

Even comparing things with JPL NASA is not easy;-) There are a lot of parameters that are needed to compare.

All the best,

Victor

On Tue, 16 Nov 2021 at 12:31, Batu @.***> wrote:

@vreijs https://github.com/vreijs It really doesn't matter what I compare it with because the R code computing the same output to six significant digits for both Moshier ephemeris and (supposedly) Swiss ephemeris, that should be enough to prove there is something wrong here.

But to answer your question, I compared the result to multiple astrology websites and software (e.g. astro-seek.com). In the example above I used 01/01/2000 12:00:00 UTC. The swephR package computes sun's longitude as 2.803689e+02=~280.37 degrees, other software I used compute it as 10.22 degrees Capricorn (=280.22 degrees).

I am not a programmer and just attempting something here with your package, so I don't even know how to use other fancy astronomy data calculators, if there are any.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/61#issuecomment-970181616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFU5XDWRKWKR3OEY7Q3UMI6KRANCNFSM5HYFJK3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

batuozdemir commented 2 years ago

astro-seek.com computes 10.22 degrees Capricorn, yes.

But can you also comment on the fact that my code computes the same longitude to six digits using both FLG_SWIEPH and FLG_MOSEPH?

vreijs commented 2 years ago

astro-seek.com does not help me. What program/page is used? I have no account. Can you ask them the underlying formula/accuracy/ephemeris for that program/page? Without that information it has no sense to study which is better/more accurate.

That both ephermerii in swiss ephemeris provide the same 6 decimals (for epoch 2000), is no a problem as both are quite accurate around that epoch. Did you try to show more digits in R:

options(digits=14)

All the best,

Victor

On Tue, 16 Nov 2021 at 12:42, Batu @.***> wrote:

astro-seek.com computes 10.22 degrees Capricorn, yes.

But can you also comment on the fact that my code computes the same longitude to six digits using both FLG_SWIEPH and FLG_MOSEPH?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rstub/swephR/issues/61#issuecomment-970188820, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDLUFVXCDGI7KB3GW7Q423UMI7RBANCNFSM5HYFJK3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

batuozdemir commented 2 years ago

You are right, there are slight changes in later digits, sorry for that.

Turns out the code is computing the right output, but I didn't realize other programs show degrees and minutes and sweph outputs numbers in base 10. This is entirely my bad, which makes the entire issue my fault. Really sorry for taking your time with this.

But since I'm communicating with you now, I want to say a big thank you for the swephR package!

rstub commented 2 years ago

No problem! Do you have an idea how we could improve the package or it's documentation so that these differences become more apparent?

BTW, here an example for the difference between the two ephermerii as a function of time:

library(swephR)

jdut <- seq(to = 3000000, by = 10000, length.out = 250)

moseph <- swe_calc_ut(jdut, SE$SUN, SE$FLG_MOSEPH)
swieph <- swe_calc_ut(jdut, SE$SUN, SE$FLG_SWIEPH)

plot(jdut,
     abs(swieph$xx[,1] - moseph$xx[,1]),
     log = "y",
     type = "l",
     xlab = "Julian Day number",
     ylab = "Longitude Diff")

Created on 2021-11-16 by the reprex package (v2.0.1)

batuozdemir commented 2 years ago

@rstub honestly I think it's not your responsibility to do more with the documentation. Your package does what it needs to perfectly. The Swiss Ephemeris documentation is (in my opinion) a bit of a mess, but fixing it is is neither your job nor it is feasible.