Karl,
Brian gave some insights already.
I'm also reluctant to use int64_t because there does not seem to be a standard
version of what the type is. Eg on OSX, int64_t is a typedef to long long. IIRC
there are cases where it is a typedef to long ...
At least with long an long long they are g
Le 20 sept. 2013 à 02:31, Patrick Welche a écrit :
> On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
>> In Rcpp we'd like to do something useful for types such as long long
>> and unsigned long long.
> ...
>> But apparently this is still not enough and on some versions o
On 20/09/2013 03:04, Karl Millar wrote:
Romain,
Can you use int64_t and uint_t64 instead? IMHO that would be more useful
than long long anyway.
'Writing R Extensions' does say
'Do be very careful with passing arguments between R, C and FORTRAN
code. In particular, long in C will be 32-bit o
Romain,
Can you use int64_t and uint_t64 instead? IMHO that would be more useful
than long long anyway.
Karl
On Sep 19, 2013 5:33 PM, "Patrick Welche" wrote:
> On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
> > In Rcpp we'd like to do something useful for types such
On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote:
> In Rcpp we'd like to do something useful for types such as long long
> and unsigned long long.
...
> But apparently this is still not enough and on some versions of gcc
> (e.g. 4.7 something), -pedantic still generates the
Hello,
In Rcpp we'd like to do something useful for types such as long long
and unsigned long long.
For example, supporting our usual wrap construct. We'd like to be able
to "wrap" a long long, or perhaps a std::vector so that it is
returned to the R side in something meaningful (we are cons
Simon
Your idea to use SQLite and the nature of some of the sorting and
extracting you are suggesting makes me wonder why you are thinking of R
data structures as the home for the data storage. I would be inclined to
put the data in an SQL database as the prime repository, then extract
parts
Dear Brian,
many thanks, that is great.
Best regards,
Ioannis
On 19/09/13 12:15, Prof Brian Ripley wrote:
The issue is underflow to zero in bd0 (C file src/nmath/bd.c). We'll
fix that, but given the R 3.0.2 RC is in code freeze and this has
existed for years, not for 3.0.2.
On 18/09/2013 23:
On 13-09-18 1:47 PM, Yihui Xie wrote:
Hi,
The imaginary unit is gone in the 'text' column in the returned data
frame from getParseData(), e.g. in the example below, perhaps the text
should be 1i instead of 1:
Yes, I can confirm the bug. I'll fix it in R-devel now, and in
R-patched after 3.0.
The issue is underflow to zero in bd0 (C file src/nmath/bd.c). We'll
fix that, but given the R 3.0.2 RC is in code freeze and this has
existed for years, not for 3.0.2.
On 18/09/2013 23:52, Kosmidis, Ioannis wrote:
Dear all,
we received a bug report for betareg, that in some cases the optim
This is nothing to do with CRAN policies (nor R).
The issue is that the current upquote.sty does not play with 'ae' fonts
as used by default by Sweave. The change is in TeX.
And that was what Spencer Graves was informed.
On 19/09/2013 04:35, Spencer Graves wrote:
Hello, All:
The v
11 matches
Mail list logo
