JC,
Are you going to call this new abbreviated language by the name "Q" or keep
calling itby the name "R" as "S" is taken?
As a goal, yes, it is easier to maintain a language that is sparse. It may sort
of force programmers to go in particular ways to do things and those ways could
be very
Let me be clear up front that I do not want to start any major discussions,
merely to share some observations.
We discussed at length what it would mean if R was extended to allow a plus
sign to concatenate text when the operands were both of the right types that
made sense for the purpose so
Excellent reason, Duncan. R does not have an unlimited integer type as in
Python so truncating or rounding activities can well produce a result that
would be out of bounds.
If someone really wants an array of integers, other than efficiency reasons,
they could process the output from something
out, any kind of behavior one wants from string
concatenation can be implemented by custom operators as needed. This is not
something that needs to be in the base R. I would rather like the efforts to be
directed on improving string formatting (such as glue-style built-in string
interpolation).
— T
After seeing what others are saying, it is clear that you need to carefully
think things out before designing any implementation of a more native
concatenation operator whether it is called "+' or anything else. There may
not be any ONE right solution but unlike a function version like paste()
Grant,
One nit to consider is that the default behavior of pasteo() to include a space
as a separator would not be a perfect choice for the usual meaning of plus.
I would prefer a+b to be "helloworld" in your example and to get what you say
would be
a + " " + b
Which I assume would put in
R wobbles a bit as there is no normal datatype that is a singleton variable.
Saying x <- 5 just creates a vector of current length 1. It is perfectly legal
to then write x [2] <- 6 and so on. The vector lengthens. You can truncate it
back to 1, if you wish: length(x) <- 1
So the question here
c: r-devel@r-project.org
Subject: Re: [Rd] order of operations
It could be that the two sides of * are run in parallel in the future and maybe
not having a guarantee would simplify implementation?
On Fri, Aug 27, 2021 at 12:35 PM Avi Gross via R-devel
wrote:
>
> Does anyone h
Does anyone have a case where this construct has a valid use?
Didn't Python add a := operator recently that might be intended more for
such uses as compared to using the standard assignment operators? I wonder
if that has explicit guarantees of what happens in such cases, but that is
outside
Greg,
I am curious what they suggest you use multiple NaN values for. Or, is it
simply like how text messages on your phone started because standard size
packets were bigger than what some uses required so they piggy-backed messages
on the "empty" space.
If by NaN you include the various
uld not be discarded.
After all, the NA is nothing but a tagged NaN.
All the best,
Adrian
On Tue, May 25, 2021 at 7:05 AM Avi Gross via R-devel mailto:r-devel@r-project.org> > wrote:
I was thinking about how one does things in a language that is properly
object-oriented versus R tha
I was thinking about how one does things in a language that is properly
object-oriented versus R that makes various half-assed attempts at being such.
Clearly in some such languages you can make an object that is a wrapper that
allows you to save an item that is the main payload as well as
Adrian,
This is an aside. I note in many machine-learning algorithms they actually do
something along the lines being discussed. They may take an item like a
paragraph of words or an email message and add thousands of columns with each
one being a Boolean specifying if a particular word is
R!
From: Adrian Dușa mailto:dusa.adr...@unibuc.ro> >
Sent: Monday, May 24, 2021 5:26 AM
To: Avi Gross mailto:avigr...@verizon.net> >
Cc: r-devel mailto:r-devel@r-project.org> >
Subject: Re: [Rd] 1954 from NA
Hmm...
If it was only one column then your solution is neat. Bu
Arguably, R was not developed to satisfy some needs in the way intended.
When I have had to work with datasets from some of the social sciences I have
had to adapt to subtleties in how they did things with software like SPSS in
which an NA was done using an out of bounds marker like 999 or "."
Just to be different, the premise was that you do not know how many dimensions
the array had. But that is easily available using dim() including how many
items are in each dimension. So, in principle, you can use a normal indexing
method perhaps in a loop to get what you want. Not sexy but
Gabor,
Although it might be nice if all imagined cases worked, there are many ways to
work around and get the results you want.
You may want to consider that it is easier to recognize the symbol you use (x
in the examples) if it is alone and used only exactly once and it the list of
function
Antoine,
Have you considered converting the non-list to a list explicitly so this
does not matter?
For a long time, few people used lists in this context, albeit in the
tidyverse it is now better supported and probably more common.
This is an area many have found annoying when you have implicit
Thank you for explaining, Ed. It makes looking at the issue raised much
easier.
As I understand it, you are not really asking about some thing fully in your
control. You are asking how any function like quantile() should behave when
a user has altered something global or at least global within
Question: is the part that Ed Merkle is asking about the change in the
expected NAME associated with the output?
He changed a sort of global parameter affecting how many digits he wants any
compliant function to display. So when he asked for a named vector, the
chosen name was based on his
It has been very enlightening watching the discussion not only about the
existing and proposed variations of a data "pipe" operator in R but also
cognates in many other languages.
So I am throwing out a QUESTION that just asks if the pipeline as done is
pretty much what could also be done without
., Avi Gross via R-devel wrote:
> As someone who switches back and forth between using standard R methods and
> those of the tidyverse, depending on the problem, my mood and whether Jupiter
> aligns with Saturn in the new age of Aquarius, I have a question about the
> forthcoming b
As someone who switches back and forth between using standard R methods and
those of the tidyverse, depending on the problem, my mood and whether Jupiter
aligns with Saturn in the new age of Aquarius, I have a question about the
forthcoming built-in pipe. Will it motivate anyone to eventually
Topic is more about anonymous functions but also pipes.
Rui thought the proposed syntax was a bit ugly. I assume the \(x) ... was what
he means, not the function(x)... version.
Many current languages have played games on adding some form of anonymous
function that is defined and used in place.
Naming is another whole topic.
I have seen suggestions that the current pipeline symbol used be phrased as
THEN so
data %>% f1 %>% f2()
would be said as something like:
take data then apply f1 then f2
or some variants.
There are words other than pipe or pipeline that might also work such as
Luke and others,
Can anyone comment on how this new pipe operator will interoperate with
existing pipe methods or packages like the tidyverse that currently do things
using them?
What differences might it make for efficiency? For example, making an anonymous
function just so you can call
26 matches
Mail list logo
