I know of 2. there is the standard one I presume you already know
http://cran.r-project.org/doc/manuals/R-ints.html
But there is another, more comprehensive one. It's written in a few
languages as well. Mostly C. :-)
Bill Venables
CSIRO Laboratories
PO Box 120, Cleveland, 4163
AUSTRALIA
Off
I'm interested in doing a little programming on the R engine. Can
anyone point me toward a document which details the internals?
Thanks. --Jon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
On Wednesday 23 May 2007 1:29 pm, Prof Brian Ripley wrote:
> No, because it is carefully documented to do this, and people rely on it
> working as documented. (Did you do the homework the posting guide asked
> for?) What harm came out of learning that the values were not finite?
I read the manpa
(Added Debian BTS address for this bug report back on CCs --edd)
Brian,
Thanks for not letting this fall off the wagon.
On 23 May 2007 at 21:08, [EMAIL PROTECTED] wrote:
| I looked for evidence that this is supposed to happen, as it was news to
| me that it did on some versions of R. Possibl
I looked for evidence that this is supposed to happen, as it was news to
me that it did on some versions of R. Possible sources of documentation
seem to be
R CMD INSTALL --help
?INSTALL
R-intro.texi, R-exts.texi, R-admin.texi
none of which mention this AFAICS, and all seem to be written assumi
> I think this is a bug in the MacOS X runtime. I've checked the C99
> standard, and can see no limits on the precision that you should be able
> to specify to printf.
That seems quite possible - it's interesting that increasing the
number of digits (ie 1e7 vs 1e6) doesn't crash, but takes up abo
Hi Vince --
Not a solution, but a little understanding and a workaround. With C1,
what happens is that the 'names' attribute of ll gets transfered to
the 'names' attribute of the S4 instance.
> setClass("C1", contains="list")
[1] "C1"
> setClass("C2", contains="C1")
[1] "C2"
> ll <- list(a=1, b=2
I think this is a bug in the MacOS X runtime. I've checked the C99
standard, and can see no limits on the precision that you should be able
to specify to printf.
Not that some protection against such OSes would come amiss.
However, the C99 standard does make clear that [sf]printf is not requir
On 5/23/2007 11:52 AM, Oleg Sklyar wrote:
Dear all,
following the earlier discussion, I've made a couple of changes to
'inline' (http://www.ebi.ac.uk/~osklyar/inline). As announced before the
idea of the package is to enable inlining C or C++ code in R functions
using only R sources. The changes
No, because it is carefully documented to do this, and people rely on it
working as documented. (Did you do the homework the posting guide asked
for?) What harm came out of learning that the values were not finite?
On Wed, 23 May 2007, Vladimir Dergachev wrote:
>
>I have recently made a s
This is an addition to my previous message.
16 digits are indeed not sufficient to represent a double
value exactly. The next table is calculated in bc calculator.
It shows that if we restrict (or round) double values
to 16 decadic digits then from 4 to 5 consecutive distinct
double values get the
I have recently made a silly screwup by applying is.finite() to a
character vector:
> is.finite(c("a", "b"))
[1] FALSE FALSE
This does work with factors of course (as they are integer underneath)
I wonder if a fix could be put in so that it either reports an error when
applied to a chara
> > Well, okay, now what about dump, write.table, save, etc?
>
> save() uses the required precision. For exp(1) it stores
> "2.718281828459045" and you will see that
>
> exp(1) == 2.718281828459045 is TRUE
>
save(...,ascii=TRUE) uses 16 digit precision, but this seems
not to be sufficient. In
Dear all,
following the earlier discussion, I've made a couple of changes to
'inline' (http://www.ebi.ac.uk/~osklyar/inline). As announced before the
idea of the package is to enable inlining C or C++ code in R functions
using only R sources. The changes include:
- it is possible to select betwee
On 5/23/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> > On 5/23/07, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > > > "GaGr" == Gabor Grothendieck <[EMAIL PROTECTED]>
> > > > on Wed, 23 May 2007 08:56:50 -0400 writes:
> > >
On 5/23/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > > "GaGr" == Gabor Grothendieck <[EMAIL PROTECTED]>
> > > on Wed, 23 May 2007 08:56:50 -0400 writes:
> >
> >GaGr> On 5/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
On 5/23/07, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > "GaGr" == Gabor Grothendieck <[EMAIL PROTECTED]>
> > on Wed, 23 May 2007 08:56:50 -0400 writes:
>
>GaGr> On 5/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
>>> Andrew Clausen <[EMAIL PROTECTED]> writes:
>>>
>>> >
> "GaGr" == Gabor Grothendieck <[EMAIL PROTECTED]>
> on Wed, 23 May 2007 08:56:50 -0400 writes:
GaGr> On 5/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
>> Andrew Clausen <[EMAIL PROTECTED]> writes:
>>
>> > Hi Seth,
>> >
>> > On Mon, May 21, 2007 at 05:15:10PM
On 5/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
> Andrew Clausen <[EMAIL PROTECTED]> writes:
>
> > Hi Seth,
> >
> > On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote:
> >> I will also add that the notion of a default argument on a generic
> >> function seems a bit odd to me. If an arg
Andrew Clausen <[EMAIL PROTECTED]> writes:
> Hi Seth,
>
> On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote:
>> I will also add that the notion of a default argument on a generic
>> function seems a bit odd to me. If an argument is available for
>> dispatch, I just don't see what sense
# returns list(a1 = 1, a2 = 2, b = 3) with an attribute
# "reshapeLong" containing skeleton (existing reshape also uses
# "reshapeWide" and "reshapeLong" attributes)
L <- list(a = 1:2, b = 3)
long <- reshape(L, direction = "long")
# returns original list but with an attribute "reshapeWide"
resha
Hi Gabor,
Can you suggest some examples of how your proposal could be used?
Reshape never returns a vector.
Cheers,
Andrew
On Tue, May 22, 2007 at 07:36:56PM -0400, Gabor Grothendieck wrote:
> One additional idea.
>
> I wonder if reshape might be promoted to a generic and relist made
> into met
> I think the only way this would affect your package is that you need to
> be able to handle embedded newlines in strings, but I can't see why you
> wouldn't be able to do that automatically.
That would be no problem if there were such a thing. As for now, I think
the Deepayan's solution for multi
> That is actually a (rare) case that can be completely vectorized:
Thanks for the vectorization solution.
> I really like the idea! Except for the fact that it's forcing the use of
> C++ which adds unnecessary overhead :P
I can make it optional. I was just thinking that C++ would be more
general
On 5/23/07, hadley wickham <[EMAIL PROTECTED]> wrote:
> On 5/22/07, Uwe Ligges <[EMAIL PROTECTED]> wrote:
> >
> >
> > Zack Weinberg wrote:
> > > I have noticed that in R 2.5.0, no method of textual output will print
> > > a "double" mode quantity with more than 15 digits after the decimal
> > > poi
On 5/22/07, Uwe Ligges <[EMAIL PROTECTED]> wrote:
>
>
> Zack Weinberg wrote:
> > I have noticed that in R 2.5.0, no method of textual output will print
> > a "double" mode quantity with more than 15 digits after the decimal
> > point. From the help page (?print.default) it appears that this is
> >
Zack Weinberg wrote:
> On 5/22/07, Uwe Ligges <[EMAIL PROTECTED]> wrote:
>> Zack Weinberg wrote:
>> >
>> > I'd really appreciate some way of forcing R to print enough digits to
>> > represent every possible IEEE double value. I would also argue that
>> > this should be the default behavior of du
27 matches
Mail list logo
