Re: [Gretl-devel] Rlib daily update!

I've now run some timings[see endnote] and I'm satisfied that use of Rlib dominates calling the R executable. Therefore, when Rlib support is present and the library can be opened, we use it by preference. I've removed "set R_lib", but have added an environment variable, GRETL_NO_RLIB, which if set blocks the use of Rlib in favour of the R executable (just for testing). I've also added an item to Tools/Preferences/General, Programs tab, to set the path to the R library in case it's not correctly detected. Now to a comment from Sven: Me: Sven: This is now moot since "set R_lib on" is gone. But the same question arises in relation to "set R_functions on". At present that gives a warning: an error message appears only if the "R_functions" facility is actually used. But perhaps it should be an error from the start. Note on timings. First, the clock() function that we've been using up till now for the gretl stopwatch can't do the job of comparing libR and R, since it doesn't include the time taken by child processes (i.e. a call to the R executable always appears to takes zero time!). I've substituted the times() function where it's available (via a configure-time test). So far as I know times() is not available on Windows, but I'll try digging further. Anyway, I've been messing with Jack's Example 27.1 from the User's Guide (Basic Structural Model). What I find is that the time to execute a sequence of R commands, in a given "foreign" block, is about the same for R and libR -- at the first call. On my machine the BSM example takes about 0.34 seconds either way. However, most of this time is taken up initializing R, and with the libR approach you pay this cost only once. If you time _two_ invocations of the BSM foreign block in one script, you get R: time approx 2 * 0.34 secs (as expected) libR: time approx 0.34 secs (nice!) Allin.