On Sun, Sep 7, 2014 at 7:03 PM, Uwe Ligges
wrote:
>
>
> On 08.09.2014 01:01, Gregory R. Warnes wrote:
>>
>> And I’ll pick up hexbin.
>
>
> Err, that one has been adopted a month ago already.
>
> open are:
>
> SemiPar cghseg monreg
I will take monreg. Coincidentally my recent research is related.
On 08.09.2014 01:01, Gregory R. Warnes wrote:
And I’ll pick up hexbin.
Err, that one has been adopted a month ago already.
open are:
SemiPar cghseg monreg
Best,
Uwe Ligges
-Greg
On Sep 7, 2014, at 12:17 PM, Romain Francois wrote:
I'll pick up operators.
Le 7 sept. 2014 à 18:03, U
And I’ll pick up hexbin.
-Greg
On Sep 7, 2014, at 12:17 PM, Romain Francois wrote:
> I'll pick up operators.
>
> Le 7 sept. 2014 à 18:03, Uwe Ligges a écrit
> :
>
>>
>>
>> On 05.09.2014 20:25, Greg Snow wrote:
>>> Uwe,
>>>
>>> Have all of these packages found new maintainers? if not, wh
Please change this. R should not confuse people with things that have some
issues to be put in practice because of comercial (yes) strategies. I have been
working in TI area for about 10 years. And have been studying computing related
subjects for almost 15 years.
The use of KB, MB, ... as base
1) Your question is no longer related to lbfgsb. It is common to start a
new thread with a new Subject: for new questions.
2) You do not show your name or affiliation. That is generally frowned upon
around here.
3) Your question was about RInside / Rcpp. We prefer those questions over
on the
I cannot remember if this has already been discussed or not, and I'm a
bit worried I'm throwing off an endless debate. If it's already
settled, no need to discuss it further.
TOPIC #1:
Shouldn't R use KB, MB and GB when reporting on sizes kilobytes,
megabytes and gigabytes? More specifically, fo
I'll pick up operators.
Le 7 sept. 2014 à 18:03, Uwe Ligges a écrit :
>
>
> On 05.09.2014 20:25, Greg Snow wrote:
>> Uwe,
>>
>> Have all of these packages found new maintainers? if not, which ones
>> are still looking to be adopted?
>
> Thanks for asking, the ones still looking to be adaopt
On 05.09.2014 20:25, Greg Snow wrote:
Uwe,
Have all of these packages found new maintainers? if not, which ones
are still looking to be adopted?
Thanks for asking, the ones still looking to be adaopted are:
SemiPar cghseg monreg operators
Best,
Uwe Ligges
thanks,
On Fri, Aug 8, 2014 at
On 7 September 2014 at 12:30, axionator wrote:
| I would like to call R's lbfgsb function from my C/C++ code by including
| R_ext/Applic.h and linking against libR.
| Currently, I am allocating memory for x (and the other input arrays for
| lbfgsb) in my C/C++ code via malloc/new. However, this gi
Maximum 0.02022958 seconds out of 10^6 runs for me, so no obvious problem on OS
X 10.9 (Snow Leopard build).
Matt
> library(microbenchmark)
> (timings <- microbenchmark(
+ normalizePath("some/network/drive", mustWork = FALSE),
+ times = 1e6,
+ unit = "s"
+ ))
Unit: seconds
Hi,
I would like to call R's lbfgsb function from my C/C++ code by including
R_ext/Applic.h and linking against libR.
Currently, I am allocating memory for x (and the other input arrays for
lbfgsb) in my C/C++ code via malloc/new. However, this gives a segmentation
fault when executing the program
On 07.09.2014 10:07, Richard Cotton wrote:
I'm having an issue with occasionally slow-running calls to
normalizePath. If the path is a non-existent UNC path, then
normalizePath sometimes takes 6 or 7 seconds to run, rather than its
usual few microseconds. My big problem is that I can't reliab
I'm having an issue with occasionally slow-running calls to
normalizePath. If the path is a non-existent UNC path, then
normalizePath sometimes takes 6 or 7 seconds to run, rather than its
usual few microseconds. My big problem is that I can't reliably
reproduce this across machines.
The example
13 matches
Mail list logo
