On 16/06/2017 20:37, Jim Hester wrote:
The relevant sections of the C standard are
http://c0x.coding-guidelines.com/5.2.4.2.1.html, which specifies that C
There is more than one C standard, but that is none of them.
ints are only guaranteed to be 16 bits, C long ints at least 32 bits in
size,
> On 16 Jun 2017, at 21:17 , Duncan Murdoch wrote:
>
> paste0("this is the first part",
>"this is the second part")
>
> If the rather insignificant amount of time it takes to execute this function
> call really matters (and I'm not convinced of that), then shouldn't it be
> solved by
The relevant sections of the C standard are
http://c0x.coding-guidelines.com/5.2.4.2.1.html, which specifies that C
ints are only guaranteed to be 16 bits, C long ints at least 32 bits in
size, as Peter mentioned. Also http://c0x.coding-guidelines.com/6.4.4.1.html
specifies l or L as the suffix for
On 16/06/2017 2:04 PM, Radford Neal wrote:
On Wed, 14 Jun 2017, G?bor Cs?rdi wrote:
I like the idea of string literals, but the C/C++ way clearly does not
work. The Python/Julia way might, i.e.:
"""this is a
multi-line
lineral"""
luke-tier...@uiowa.edu:
This does look like a promising opt
On Fri, 16 Jun 2017, Dario Strbenac wrote:
Good day,
It's not described anywhere in the help page, but tapply and by
functions will, by default, convert factors into numeric values. Perhaps
this needs to be documented or the behaviour changed.
It *is* described in the help page.
This re
On Fri, Jun 16, 2017 at 1:14 PM, Gábor Csárdi wrote:
> On Fri, Jun 16, 2017 at 7:04 PM, Radford Neal wrote:
>>> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote:
>>>
>>> > I like the idea of string literals, but the C/C++ way clearly does not
>>> > work. The Python/Julia way might, i.e.:
>>> >
>>> > """th
"Writing R Extensions" says "int":
R storage mode C type FORTRAN type
logical int* INTEGER
integer int* INTEGER
double double* DOUBLE PRECISION
complex Rcomplex* DOUBLE COMPLEX
character char** CHARACTER*255
raw unsigned char* none
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fr
Wikipedia claims that C ints are still only guaranteed to be at least 16 bits,
and longs are at least 32 bits. So no, R's integers are long.
-pd
> On 16 Jun 2017, at 20:20 , William Dunlap via R-devel
> wrote:
>
> But R "integers" are C "ints", as opposed to S "integers", which are C
> "long
But R "integers" are C "ints", as opposed to S "integers", which are C
"long ints". (I suppose R never had to run on ancient hardware with 16 bit
ints.)
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Jun 16, 2017 at 10:47 AM, Yihui Xie wrote:
> Yeah, that was what I heard from our instru
On Fri, Jun 16, 2017 at 7:04 PM, Radford Neal wrote:
>> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote:
>>
>> > I like the idea of string literals, but the C/C++ way clearly does not
>> > work. The Python/Julia way might, i.e.:
>> >
>> > """this is a
>> > multi-line
>> > lineral"""
>>
>> luke-tier...@uio
> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote:
>
> > I like the idea of string literals, but the C/C++ way clearly does not
> > work. The Python/Julia way might, i.e.:
> >
> > """this is a
> > multi-line
> > lineral"""
>
> luke-tier...@uiowa.edu:
> This does look like a promising option; some more ca
Yeah, that was what I heard from our instructor when I was a graduate
student: L stands for Long (integer).
Regards,
Yihui
--
https://yihui.name
On Fri, Jun 16, 2017 at 11:00 AM, Serguei Sokol wrote:
> Le 16/06/2017 à 17:54, Henrik Bengtsson a écrit :
>>
>> I'm just curious (no complaints), wha
> On 16 Jun 2017, at 15:59 , Robert McGehee wrote:
>
> For instance, what would you expect to get from unlist() if each element of
> the list had different levels, or were both ordered, but in a different way,
> or if some elements of the list were factors and others were ordered factors?
>> u
Hi Paul,
Now I see what you're getting at. I misread your original mail completely.
So we definitely agree, and wholeheartedly even.
The use case you just gave, is definitely in my top 5 of frustrations about
R. I would like to be able to assign the same label to multiple levels
without having to
On Fri, Jun 16, 2017 at 2:35 AM, Joris Meys wrote:
> To extwnd on Martin 's explanation :
>
> In factor(), levels are the unique input values and labels the unique output
> values. So the function levels() actually displays the labels.
>
Dear Joris
I think we agree. Currently, factor insists bot
Le 16/06/2017 à 17:54, Henrik Bengtsson a écrit :
I'm just curious (no complaints), what was the reason for choosing the
letter 'L' as a suffix for integer constants? Does it stand for
something (literal?), is it because it visually stands out, ..., or no
specific reason at all?
My guess is tha
I'm just curious (no complaints), what was the reason for choosing the
letter 'L' as a suffix for integer constants? Does it stand for
something (literal?), is it because it visually stands out, ..., or no
specific reason at all?
/Henrik
__
R-devel@r-p
This can be traced back to the following line in unlist():
structure(res, levels = lv, names = nm, class = "factor")
The Details section of ?unlist states specifically how it treats factors,
so this is documented and expected behaviour.
This is also the appropriate behaviour. In your case one co
Hi,
It's been my experience that when you combine or aggregate vectors of factors
using a function, you should be prepared for surprises, as it's not obvious
what the "right" way to combine factors is (ordered or not), especially if two
vectors of factors have different levels or (if ordered) ar
>> I don't think it is reasonable to change the parser this way. This is
>> currently valid R code:
>>
>> a <- "foo"
>> "bar"
>>
>> and with the new syntax, it is also valid, but with a different
>> meaning. Or you can even consider
>>
>> a <- "foo"
>> bar %>% func() %>% print()
>>
>> etc.
>>
>> I
Dear all,
I don't know if you consider this a bug or feature, but it breaks reasonable
code: 'unlist' and 'sapply' convert 'ordered' to 'factor' even if all levels
are equal. Here is a simple example:
o <- ordered(letters)
o[[1]]
lapply(o, min)[[1]] # ordered factor
unlist(lapply(o, m
To extwnd on Martin 's explanation :
In factor(), levels are the unique input values and labels the unique
output values. So the function levels() actually displays the labels.
Cheers
Joris
On 15 Jun 2017 17:15, "Martin Maechler" wrote:
> Paul Johnson
> on Wed, 14 Jun 2017 19:00:
22 matches
Mail list logo
