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
intentional, since digits after the fifteenth may be uncertain.
However, fifteen digits afte
Hi r-devel,
I've linked my windows application to the R.dll following the instructions
from the R documents,
however, my application always encounters C stack limit.
Do anyone know why and how to fix this?
Thank you very much!
[[alternative HTML version deleted]]
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
> intentional, since digits after the fifteenth may be uncertai
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 it makes to have a default. In
> those cases, the d
On May 22, 2007, at 5:33 AM, Ev Whin wrote:
> Hi r-devel,
>
> I've linked my windows application to the R.dll following the
> instructions
> from the R documents,
> however, my application always encounters C stack limit.
Are you using threads? If so, you have to disable the C stack limit
(R
This is a question and maybe an announcement.
We've been discussing in the group that it would be nice to have a
mechanism for something like "inline" C/C++ function calls in R. I do
not want to reinvent the wheel, therefore, if something like that
already exists, please give me a hint -- I could
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 dump(), write.table() and
> > fr
In addition to $ that was mentioned in this thread there is
also attr, e.g.
> names(attributes(CO2))
[1] "names" "row.names" "class" "formula" "outer" "labels"
[7] "units"
> attr(CO2, "f") # matches "formula"
uptake ~ conc | Plant
On 5/17/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
Oleg,
On May 22, 2007, at 1:59 PM, Oleg Sklyar wrote:
> We've been discussing in the group that it would be nice to have a
> mechanism for something like "inline" C/C++ function calls in R. I
> do not want to reinvent the wheel, therefore, if something like
> that already exists, please giv
> "AndrewC" == Andrew Clausen <[EMAIL PROTECTED]>
> on Tue, 22 May 2007 07:51:54 -0400 writes:
AndrewC> Hi Seth,
AndrewC> 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
On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
> This is a question and maybe an announcement.
>
> We've been discussing in the group that it would be nice to have a
> mechanism for something like "inline" C/C++ function calls in R. I do
> not want to reinvent the wheel, therefore, if something like tha
On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
> On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
>
> One suggestion that probably doesn't affect your package: It would be
> even nicer if R incorporated something that Duncan Temple Lang suggested
> last year, namely a new kind of quoting that didn'
On 22/05/2007 4:01 PM, Vladimir Dergachev wrote:
> On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
>> On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
>>
>> One suggestion that probably doesn't affect your package: It would be
>> even nicer if R incorporated something that Duncan Temple Lang suggest
On Tuesday 22 May 2007 4:58 pm, Duncan Murdoch wrote:
> On 22/05/2007 4:01 PM, Vladimir Dergachev wrote:
> > On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
> >> On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
> >
> > I second that. My favorite implementation of this is in Tcl, where curly
> > brace
Vladimir Dergachev wrote:
>
>> I think DTL's suggestion would be most useful when putting a lot of code
>> in a string, where the escapes make the code harder to read. For
>> example, just about any function using a complicated regular expression.
>>
>
> Also anything using .Tcl(). Quotes in
Hi again,
Robert has committed the proposed patch to R-devel. So [[ now has an
'exact' argument and the behavior is as described:
Seth Falcon <[EMAIL PROTECTED]> writes:
>1. [[ gains an 'exact' argument with default value NA
>
>2. Behavior of 'exact' argument:
>
> exact=NA
>
One additional idea.
I wonder if reshape might be promoted to a generic and relist made
into methods for it. The unlisted version of an object would be the "long"
version and the original version of the list would be the "wide" version.
This would consolidate the two concepts together and make i
On Tuesday 22 May 2007 7:05 pm, Peter Dalgaard wrote:
> Vladimir Dergachev wrote:
> >> I think DTL's suggestion would be most useful when putting a lot of code
> >> in a string, where the escapes make the code harder to read. For
> >> example, just about any function using a complicated regular ex
completion is semi-broken in today's r-devel, and the reason seems to
be some regular expression changes:
> sessionInfo()
R version 2.6.0 Under development (unstable) (2007-05-22 r41673)
i686-pc-linux-gnu
locale:
[...]
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "
Deepayan,
Thanks. One bug fix had tickled another here. grexexpr() is not much
used in R and when I wrote a regression suite for grep and friends I was
suprised to find that both grepexpr(perl=TRUE) and grexepr(fixed=TRUE)
were giving incorrect results in MBCSs (provided multibyte characters
20 matches
Mail list logo
