Thanks for this version code!
I see that you iitialise the 'version' string inside the C code:
char version = (char) malloc(256*sizeof(char));

But would it be possible to provide the initialisation in R function call (such as the serr string in swe_calc)? SE uses that method quiet a lot (just to keep semantics similar). I tried to remove the char *version statement and put part in the std::string version(char *version), but is not liked by Rcpp...
Perhaps I am really lacking C skill...

All the best,

Victor

There is a new build failure from R devel caused by the checkbashisms script being unavailable. This script is located in the devscripts package. Travis log: https://travis-ci.org/rstub/swephR/jobs/599624813

Here are example using swetest.exe (form SE author Alois):

Examples:
Swiss Ephemeris
swetest -p1e -fPL+-*/= -b1.1.2018 -eswe
date (dmy) 1.1.2018 greg.   0:00:00 TT        version 2.07.02
TT:  2458119.500000000
Epsilon (true)    23°26' 5.6136
Nutation          -0° 0'11.5628   -0° 0' 7.3618
name            long.          phase phase elong diamet magn
Moon              84°47'14.6888   16°10'23.8764      0.980211798  163°47'15.7090    0°33'26.2108   -12.46m
Moshier:
swetest -p1e -fPL+-*/= -b1.1.2018 -emos
date (dmy) 1.1.2018 greg.   0:00:00 TT        version 2.07.02
TT:  2458119.500000000
Epsilon (true)    23°26' 5.6136
Nutation          -0° 0'11.5628   -0° 0' 7.3618
name            long.          phase phase elong diamet magn
Moon              84°47'14.9997   16°10'23.4491      0.980212087  163°47'16.1424    0°33'26.2036   -12.46m

JPL:
swetest -p1e -fPL+-*/= -b1.1.2018 -ejpl
date (dmy) 1.1.2018 greg.   0:00:00 TT        version 2.07.02
TT:  2458119.500000000
Epsilon (true)    23°26' 5.6136
Nutation          -0° 0'11.5628   -0° 0' 7.3618
name            long.          phase phase elong diamet magn
Moon              84°47'14.6891   16°10'23.8665      0.980211805  163°47'15.7190    0°33'26.2108   -12.46m

Because Moshier Moon can differ slightly (0.3 arcsec in this example from JPL/Swisseph, there are of course small differences in phase and elongation.

I will try to see if I can reproduce these and if Moshier changes when the SWIEPH is loaded...

I have some unexpected results from swe_fixstar(2):
It looks swe_fixstar works ok:

swe_set_ephe_path("")
swe_set_topo(0,50,10)
swe_fixstar("sirius",1234567,34818)
$return
[1] 34818
$star
[1] "Sirius,alCMa"
$xx
[1] 6.465315e+01 -1.780315e+01 5.518192e+05 -3.482530e-04 1.170200e-05 -3.109594e-03
$serr
[1] "SwissEph file 'seplm18.se1' not found in PATH '\sweph\ephe\' \nusing Moshier eph.; "

swe_fistar2 should give same results, but does not provide the correct xx and starname data:

swe_fixstar2("sirius",1234567,34818)
$return
[1] -1
$star
[1] "Sirius,alCMa"
$xx
[1] 0 0 0 0 0 0
$serr
[1] "SwissEph file 'seplm18.se1' not found in PATH '\sweph\ephe\'"

Then looking at swe_fixstar_mag seems to be going wrong when called more than once with the same starname:

swe_fixstar_mag("sirius")
$return
[1] 0
$star
[1] "Sirius,alCMa"
$mag
[1] -1.46
$serr
[1] ""
swe_fixstar_mag("sirius")
$return
[1] 0
$star
[1] "sirius"
$mag
[1] 1.302323e-262
$serr
[1] ""

swe_fixstar2_mag though works ok:

swe_fixstar2_mag("sirius")
$return
[1] 0
$star
[1] "Sirius,alCMa"
$mag
[1] -1.46
$serr
[1] ""
swe_fixstar2_mag("sirius")
$return
[1] 0
$star
[1] "Sirius,alCMa"
$mag
[1] -1.46
$serr
[1] ""

What do other people see? (the authors of SE don't see this behavior, but they are of course only using complied C).

Thanks for the feedback.

Flavor: r-devel-linux-x86_64-debian-gcc
Check: whether package can be installed, Result: WARNING
Found the following significant warnings:
libswe/sweph.c:7363:5: warning: 'strncpy' output may be truncated copying 256 bytes from a string of length 275 [-Wstringop-truncation]
See '/srv/hornik/tmp/CRAN/swephR.Rcheck/00install.out' for details.

The seorbel.txt file needed for fictitious bodies is missing, c.f. https://groups.io/g/swisseph/topic/95363999#11235. It is now available from https://github.com/aloistr/swisseph/tree/master/ephe.

It might also make sense to check if sefstars.txt has been updated.

Should one also add seleapsec.txt?

Added refract_extended: (I wa snot able to push to master...)
this code in swephR.cpp

//' Compute the refraction
//' @param InAlt  The object's apparent/topocentric altitude (depending on calc_flag)
//' @param geoheight  The observer's height
//' @param lapse_rate  The lapse rate pK/m]
//' @param calc_flag SE_TRUE_TO_APP=0 or SE_APP_TO_TRUE=1
//' @return \code{swe_refrac_extended} returns a list with named entries: \code{i} success of function
//'      \code{dret} for refraction related calculations (TopoAlt, AppAlt, refraction)
//' @rdname expert-interface
//' @export
// [[Rcpp::export(swe_refrac_extended)]]
Rcpp::List refrac_extended(double InAlt, double geoheight, double atpress, double attemp, double lapse_rate, int calc_flag) {
  std::array<double, 10> dret{0.0};
  int i = swe_refrac_extended(InAlt,geoheight,atpress,attemp,lapse_rate,calc_flag, &dret[0]);
  return Rcpp::List::create(Rcpp::Named("return") = i,
                            Rcpp::Named("dret") = dret);
}

and this code in test-misc.R:

test_that("Topocentric to Apparent altitude", {
  result <- swe_refrac_extended(2,0,1013.25,15,-0.065,0)
  expect_equal(result$return, 2)
  expect_equal(result$dret[1:3], c(2.0000000, 2.2787088, 0.2787088), tolerance=.000001)
})

test_that("Apparent to Topocentric altitude", {
  result <- swe_refrac_extended(2,0,1013.25,15,-0.065,1)
  expect_equal(result$return, 1)
  expect_equal(result$dret[1:3], c(1.701016, 2.000000, 0.298984), tolerance=.000001)
})

I think that with this one, I have also all skyscpeR functions. Hope this helps.

The documentation needs some improvements. For the help pages:

• Links to the general and programmer manual

• More logical order of functions

• some simple examples

• descriptions what each function does and what it returns

A vignette would also be nice. A simple idea would be to port and explain the example programs from the programmers guide.

Hello Ralf.

Here is the code of 2.09.03: https://www.astro.com/ftp/swisseph/
and
https://www.astro.com/ftp/swisseph/src/

There are two new functions to include in the R code:
swe_houses_ex2() and
swe_houses_armc_ex2().
We propose to remove the functions that provide lesser output: swe_houses_ex() and swe_houses_armc()

Let me know when you have time, as I need to replace these two old ones with new ones.

All the best and stay healthy.

Victor

Last comment on this version:

Hi,

this release has three minor bug fixes:

• An initialization *serr = '\0'; was missing in function swe_calc(), which could lead to crashes when error messages were written.

• Sidereal positions of asteroids were wrong with ayanamshas 9-16, 21-26, 37, 38, 41, 42. (Namely, all ayanamshas whose initial date is given in UT.)

• Asteroids with ipl > 10000 (SE_AST_OFFSET): calculating with several different ayanamshas after each other did not work properly.

The first bug was intoduced with version 2.09.01.
The 2nd one exists since version 2.05, this is 5 years old.
The 3rd one exists since more than 20 years. It seems that either sidereal astrologers rarely use asteroids or they rarely use the above-mentioned ayanamshas.

Best wishes,

Dieter

The current implementation of day_of_week() is not very R-like, since it takes only a single argument of type double instead of a numeric vector.

I have tried to build the package on even more architectures using https://builder.r-hub.io/. Most builds went fine, but there where two ERRORs:

1. Rcpp not available on Solaris, c.f. https://builder.r-hub.io/status/swephR_0.1.0.tar.gz-3b64c66e872c7b3e44153cc6148320eb
2. Runtime error with sanitizers, c.f. https://builder.r-hub.io/status/swephR_0.1.0.tar.gz-6f7ce58cad5a48f69fbb315e63cd9710
   libswe/swephlib.c:3628:16: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'

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

See

https://cran.r-project.org/web/checks/check_results_simcdm.html
https://cran.r-project.org/web/checks/check_results_swephR.html

You were warned about the errors showing on Solaris in 'Writing R
Extensions' §1.6.4

• overloading of pow(, )

• use of ERR

• unconditional use of POSIX extensions such as strnlen

Please correct ASAP once all the results are in and before Feb 14 to
safely retain the package on CRAN.

In addition:

==5590==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fff748e32df at pc 0x7fc47a994408 bp 0x7fff748e3270 sp 0x7fff748e3268
READ of size 1 at 0x7fff748e32df thread T0
    #0 0x7fc47a994407 in swi_right_trim /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/swephlib.c:3586:10
    #1 0x7fc47a931030 in fixstar_cut_string /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/sweph.c:6027:3
    #2 0x7fc47a936ac1 in load_all_fixed_stars /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/sweph.c:6158:12
    #3 0x7fc47a938753 in swe_fixstar2_mag /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/sweph.c:6741:3
    #4 0x7fc47a8df67c in fixstar2_mag(Rcpp::Vector<16, Rcpp::PreserveStorage>) /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/swephR.cpp:253:14
    #5 0x7fc47a8aa4b2 in _swephR_fixstar2_mag /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/RcppExports.cpp:117:34
    #6 0x8020f6 in R_doDotCall /data/gannet/ripley/R/svn/R-devel/src/main/dotcode.c:570:17
    #7 0x9ffc89 in bcEval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:7289:21
    #8 0x9e360d in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:620:8
    #9 0xa66557 in R_execClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c
    #10 0xa63249 in Rf_applyClosure /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:1706:16
    #11 0x9e47e0 in Rf_eval /data/gannet/ripley/R/svn/R-devel/src/main/eval.c:743:12
    #12 0xb60b20 in Rf_ReplIteration /data/gannet/ripley/R/svn/R-devel/src/main/main.c:260:2
    #13 0xb654e0 in R_ReplConsole /data/gannet/ripley/R/svn/R-devel/src/main/main.c:310:11
    #14 0xb652c5 in run_Rmainloop /data/gannet/ripley/R/svn/R-devel/src/main/main.c:1086:5
    #15 0x542f8a in main /data/gannet/ripley/R/svn/R-devel/src/main/Rmain.c:29:5
    #16 0x7fc488e6711a in __libc_start_main (/lib64/libc.so.6+0x2311a)
    #17 0x42f4a9 in _start (/data/gannet/ripley/R/R-clang-SAN/bin/exec/R+0x42f4a9)

Address 0x7fff748e32df is located in stack of thread T0 at offset 31 in frame
    #0 0x7fc47a930e9f in fixstar_cut_string /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/sweph.c:6016

  This frame has 2 object(s):
    [32, 288) 's' (line 6018) <== Memory access at offset 31 underflows this variable
    [352, 512) 'cpos' (line 6020)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-underflow /data/gannet/ripley/R/packages/tests-clang-SAN/swephR/src/libswe/swephlib.c:3586:10 in swi_right_trim

(Similar errors also from valgrind.

Thank you very much for your work to port SwissEph into R.
I'm trying to replicate Delta T by using swe_deltat_ex(jd_ut, ephe_flag). However, the function swe_jdet_to_utc to transform ET to UT to derive jd_ut is not available in Section 7: Date and time conversion functions. In principle I would like to replicate the output from swewin32.exe, which comes along with the source code to verify my R code. Do you plan to add the functions from 7.2 as well?

I get several compiling errors in the sweph C code. Do we need to solve these before we put it on CRAN? So do we need to start working on this on the swisseph e-group?
I can provide an updated version (I think I got the last few days a new error;-) Let me know.

Currently only day_of_week is vectorized. Methods like swe_calc or swe_fixstar take two arguments that could be used for vectorization: the date and the object. From my point of view one cannot rule out either of these arguments for vectorization. So for a simple interface that stays close to the C API I can imagine two extensions. In both cases the returned coordinates will form a NumericMatrix instead of a NumericVector and both date and object are of appropriate vector type:

1. Only one of the arguments date and object is allowed to have length > 1. So one can either compute many objects for one date or one object for many dates.

2. Both arguments date and object must have the same length. The n. position corresponds to the n. date and n. object.

@vreijs Which form do you think is most useful?

CRAN has started to turn on the compiler option -Wstrict-prototypes on some platforms leading to new WARN:

Version: 0.3.0
Check: whether package can be installed
Result: WARN
Found the following significant warnings:
./libswe/swephlib.h:120:33: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
./libswe/swephlib.h:130:34: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swejpl.c:949:24: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1183:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1368:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1445:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1459:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1764:26: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swemmoon.c:1821:22: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
./libswe/swepcalc.h:120:33: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swepcalc.c:373:26: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swephlib.c:3001:33: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/swephlib.c:3033:26: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
libswe/sweph.c:7099:27: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
Flavor: r-devel-linux-x86_64-fedora-clang

Version: 0.3.0
Check: whether package can be installed
Result: WARN
Found the following significant warnings:
libswe/swephlib.h:120:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
libswe/swephlib.h:130:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
libswe/swepcalc.h:120:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
libswe/swepcalc.c:373:7: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
libswe/sweph.c:7099:6: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
libswe/swephlib.c:3033:7: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
Flavor: r-devel-linux-x86_64-fedora-gcc

• Reproduce locally
• Build a patch for SE
• communicate the patch upstream

Amazing what different principles can be use din function calls;-) But I think I got it to work:

swe_set_topo(0,50,10)
swe_set_ephe_path("c:\ARCHAEOCOSMO\ephe")
swe_fixstar("sirius",123456,34818)
$return
[1] 34818
$star
[1] "Sirius,alCMa"
$xx
[1] 3.175829e+01 -2.804553e+01 5.592892e+05 8.725749e-04 -3.930304e-04 7.815862e-03
$serr
[1] "SwissEph file 'seplm48.se1' not found in PATH 'c:\ARCHAEOCOSMO\ephe\'"

It works. But perhaps it can be optimised. Let me know.

ARCHAEOCOSMO will be the first "client" package to use swephR. Here the required methods:

• swe_azalt
• swe_calc
• swe_day_of_week
• swe_deltat
• swe_deltat_ex
• swe_fixstar2
• swe_fixstar2_mag
• swe_get_tid_acc
• swe_heliacal_angle
• swe_heliacal_pheno_ut
• swe_heliacal_ut
• swe_lun_eclipse_how
• swe_lun_eclipse_when
• swe_pheno_ut
• swe_rise_trans
• swe_rise_trans_true_hor
• swe_set_delta_t_userdef
• swe_set_ephe_path
• swe_set_topo
• swe_sol_eclipse_when_loc
• swe_topo_arcus_visionis
• swe_version
• swe_vis_limit_mag

Available but not used functions:

• swe_difdegn
• swe_pheno
• swe_set_jpl_file
• swe_sol_eclipse_how
• swe_sol_eclipse_when_glob

I 'activated' swe_heliacal_ut in testheliacal.R (and in test-misc.R), but it causes instability of RStudio (makes it restart). RStudio restarts after running several times (can't yet reproduce it how many times, soemtiem sit looks one even) the swe_heliacal_ut function . So all looks ok (and the correct results are printed) and then after a few seconds RStudio restarts. If I use my ARCHAEOCOSMO functions (which uses swe_heliacal_ut): no restart happens. Don't yet know how to debug....
The dret results of swe_heliacal_ut has these very large/small numbers, perhaps that does some damage?

Current R devel treats some more warnigns as "significant": https://travis-ci.org/rstub/swephR/jobs/527752684

Upstream has released a new version: https://groups.io/g/swisseph/message/7522

In the process of migrating to that version, we should also document the necessary steps. Preliminary run book:

• unpack upstream tar.gz in external
• review/adjust/delete our patches in external/patch
• update source files in src/libswe and inst/ephe

Currently only the internal calculations are used. To achieve higher precision, it is necessary to load external data files.

The PDF manual contains several places where lines are not properly broken.

I get this error sometimes directly after pressing 'Install and Rebuilt' in RStudio::
"Error in library.dynam.unload(name, system.file(package = name)) :
DLL ‘swephR.dll’ was not loaded

Restarting R session..."

Don't think it is serious, but just wondering.

See https://cran.r-project.org/web/checks/check_results_swephR.html .
The stack overflow WRITE is very serious, so please correct ASAP and
before Jul 12 to safely retain the package on CRAN.

Feature request from SE's mailing list:

I would love to be able to use Lahiri Ayanamsa as well as play with mean v. true node setting (what is called Rahu/Ketu in the Indian system).

The first part is probably from section 10, which we have not covered so far. Not sure about the second part.

Hello Ralf, If I make changes and they don't work... Should I still push it to GitHub?

I tried to add the function:
I put this in swephapi.h:
void swe_set_ephe_path(char file);

and I put this in swephR.cpp:
//' Set the directory for the sefstar.txt and jpl files
//' @param file the directory plus file (char)
//' @export
// [[Rcpp::export]]
void set_ephe_path(char file) {
swe_set_ephe_path(file);
}

compile (all ok) and want to use it with: set_ephe_path("C:\ARCHAEOCOSMO\ephe")

R crashes... (C:\ARCHAEOCOSMO\ephe is a valid directory on my system). Any advice how to learn C (aka C for beginners)?

All the best,

Victor

P.S. By the way I get an warning:
"In file included from swephR.cpp:2:0:
swephapi.h:10:14: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long]
typedef long long int64;
^"
I think it be simply one(1) 'long' in swephapi.h, but I might misunderstand (I see 'long long' also in the original file)

Hello Ralf, I have been thinking about the naming of the external functions. Perhaps we should add 'swephR_'. Just to make sure that conflict of names not less likely. What do you think?

All the best,

Victor

Release v0.2.0 was bitten by ASSAN errors found only CRAN, even though rhub::check_with_sanitizers() was used:

• Try to understand why this error was not found
• Implement a testing scheme to find such problems reliably

Maybe interesting: rocker-org/r-devel-san#3 and https://github.com/jeroenooms/curl/blob/master/docker/r-devel-san/Dockerfile

In the documentation we have lot's of links like http://www.astro.com/swisseph/swephprg.htm?lang=g#_Toc505244831, which used to go to specific sections in the manual. With the new upstream release, these links are broken. I don't think it makes sense to update these links for every release, so it is probably best to only refer to

Section xy in http://www.astro.com/swisseph/swephprg.htm

In eclipse_pheno.cpp the line:
int i = swe_refrac_extended(InAlt,geoheight,atpress,attemp,lapse_rate,calc_flag, dret.begin());
should be
double i = swe_refrac_extended(InAlt,geoheight,atpress,attemp,lapse_rate,calc_flag, dret.begin());

All the best,

Victor

Here is the feedback from SE on the copyright:
"Hi

you must publish your project under Gnu Public License 2 or later.

I thought that was obvious from the license conditions in each of the Swiss Ephemeris source files, which say

If the developer choses the GNU GPL software license, he or she must fulfill
the conditions of that license, which includes the obligation to place his
or her whole software project under the GNU GPL or a compatible license.
See http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
"

When installed for the very first time swephR on a new computer, I got this error message (in SE code):
libswe/swepcalc.c:121:41: warning: 'rspeed' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (pspe != NULL) pspe [planet] = swe_d2l (rspeed * DEG);

I only saw it ones... Don't know if we can solve this (or I need to ask SE authors)?