Re: [Rd] question
mark.braving...@csiro.au wrote:
>
>> The syntax for returning multiple arguments does not strike me as
>> particularly appealing. would it not possible to allow syntax like:
>>
>> f= function() { return( rnorm(10), rnorm(20) ) }
>> (a,d$b) = f()
>>
>>
>
>
> FWIW, my own solution is to define a "multi-assign operator":
>
> '%<-%' <- function( a, b){
> # a must be of the form '{thing1;thing2;...}'
> a <- as.list( substitute( a))[-1]
> e <- sys.parent()
> stopifnot( length( b) == length( a))
> for( i in seq_along( a))
> eval( call( '<-', a[[ i]], b[[i]]), envir=e)
> NULL
> }
>
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i > length(b). another idea is to allow %<-% to
be used with just one variable on the lhs.
here's a modified version:
'%<-%' <- function(a, b){
a <- as.list( substitute(a))
if (length(a) > 1)
a <- a[-1]
if (length(a) > length(b))
b <- c(b, rep(list(NULL), length(a) - length(b)))
e <- sys.parent()
for( i in seq_along( a))
eval( call( '<-', a[[ i]], b[[i]]), envir=e)
NULL }
{a; b} %<-% 1:2
# a = 1; b = 2
a %<-% 3:4
# a = 3
{a; b} %<-% 5
# a = 5; b = NULL
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, wrote:
> Gentlemen---these are all very clever workarounds, but please forgive me for
> voicing my own opinion: IMHO, returning multiple values in a statistical
> language should really be part of the language itself. there should be a
> standard syntax of some sort, whatever it may be, that everyone should be
> able to use and which easily transfers from one local computer to another.
> It should not rely on clever hacks in the .Rprofile that are different from
> user to user, and which leave a reader of end user R code baffled at first
> by all the magic that is going on. Even the R tutorials for beginners should
> show a multiple-value return example right at the point where function calls
> and return values are first explained.
>
> I really do not understand why the earlier implementation of "multiple-value
> returns" was deprecated. then again, I am a naive end user, not a computer
> language expert. I probably would not even understand the nuances of syntax
> ambiguities that may have arisen. (this is my shortcoming.)
>
> regards,
>
> /iaw
>
>
> On Mar 7, 2009 4:34am, Wacek Kusnierczyk
> wrote:
>> mark.braving...@csiro.au wrote:
>>
>> >
>>
>> >> The syntax for returning multiple arguments does not strike me as
>>
>> >> particularly appealing. would it not possible to allow syntax like:
>>
>> >>
>>
>> >> f= function() { return( rnorm(10), rnorm(20) ) }
>>
>> >> (a,d$b) = f()
>>
>> >>
>>
>> >>
>>
>> >
>>
>> >
>>
>> > FWIW, my own solution is to define a "multi-assign operator":
>>
>> >
>>
>> > '%
>> > # a must be of the form '{thing1;thing2;...}'
>>
>> > a
>> > e
>> > stopifnot( length( b) == length( a))
>>
>> > for( i in seq_along( a))
>>
>> > eval( call( '
>> > NULL
>>
>> > }
>>
>> >
>>
>>
>>
>> you might want to have the check less stringent, so that rhs may consist
>>
>> of more values that the lhs has variables. or even skip the check and
>>
>> assign NULL to a[i] for i > length(b). another idea is to allow %
>> be used with just one variable on the lhs.
>>
>>
>>
>> here's a modified version:
>>
>>
>>
>> '%
>> a
>> if (length(a) > 1)
>>
>> a
>> if (length(a) > length(b))
>>
>> b
>> e
>> for( i in seq_along( a))
>>
>> eval( call( '
>> NULL }
>>
>>
>>
>> {a; b} %
>> # a = 1; b = 2
>>
>> a %
>> # a = 3
>>
>> {a; b} %
>> # a = 5; b = NULL
>>
>>
>>
>>
>>
>> vQ
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Gentlemen---these are all very clever workarounds, but please forgive me
for voicing my own opinion: IMHO, returning multiple values in a
statistical language should really be part of the language itself. there
should be a standard syntax of some sort, whatever it may be, that everyone
should be able to use and which easily transfers from one local computer to
another. It should not rely on clever hacks in the .Rprofile that are
different from user to user, and which leave a reader of end user R code
baffled at first by all the magic that is going on. Even the R tutorials
for beginners should show a multiple-value return example right at the
point where function calls and return values are first explained.
I really do not understand why the earlier implementation
of "multiple-value returns" was deprecated. then again, I am a naive end
user, not a computer language expert. I probably would not even understand
the nuances of syntax ambiguities that may have arisen. (this is my
shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
wrote:
> mark.braving...@csiro.au wrote:
> >
> >> The syntax for returning multiple arguments does not strike me as
> >> particularly appealing. would it not possible to allow syntax like:
> >>
> >> f= function() { return( rnorm(10), rnorm(20) ) }
> >> (a,d$b) = f()
> >>
> >>
> >
> >
> > FWIW, my own solution is to define a "multi-assign operator":
> >
> > '%
> > # a must be of the form '{thing1;thing2;...}'
> > a
> > e
> > stopifnot( length( b) == length( a))
> > for( i in seq_along( a))
> > eval( call( '
> > NULL
> > }
> >
> you might want to have the check less stringent, so that rhs may consist
> of more values that the lhs has variables. or even skip the check and
> assign NULL to a[i] for i > length(b). another idea is to allow %
> be used with just one variable on the lhs.
> here's a modified version:
> '%
> a
> if (length(a) > 1)
> a
> if (length(a) > length(b))
> b
> e
> for( i in seq_along( a))
> eval( call( '
> NULL }
> {a; b} %
> # a = 1; b = 2
> a %
> # a = 3
> {a; b} %
> # a = 5; b = NULL
> vQ
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
hi gabor: this would be difficult to do. I don't think you want to
read my programs. it would give you an appreciation of what ugly
horror programs end users can write in the beautiful R language ;-).
clearly, one can work around the lack of such a feature.
multiple-return values are syntax sugar. but maybe it helps to
explain how I got to my own view. I had to send an R program to
someone who had never used it before. without knowing R, he could
literally read the entire program. the only thing that stumped him
was the multiple return values. In my program, he saw
f= function() { return(list(a=myvector1, b=myvector2)) }
result=f()
a= result$a
b= result$a
rm(result)
I had picked this method up over the years reading r-help. of course,
I had 10 return values, not two, each return value with its own long
name. I think it would have been a whole lot nicer if I could have
written FOR HIM simply
f= function() { return(myvector1,myvector2); }
(a,b)= f()
again, its syntax sugar. I would find such syntax a whole lot more
appealing. and I often write functions that pass back a main program,
but also some debug or other information. maybe I am the only one...
regards,
/iaw
On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
wrote:
> Why? Can you demonstrate any situations where its useful? Despite
> having my own facility for this I've found that over the years I
> have never used it.
>
> On Sat, Mar 7, 2009 at 9:23 AM, wrote:
>> Gentlemen---these are all very clever workarounds, but please forgive me for
>> voicing my own opinion: IMHO, returning multiple values in a statistical
>> language should really be part of the language itself. there should be a
>> standard syntax of some sort, whatever it may be, that everyone should be
>> able to use and which easily transfers from one local computer to another.
>> It should not rely on clever hacks in the .Rprofile that are different from
>> user to user, and which leave a reader of end user R code baffled at first
>> by all the magic that is going on. Even the R tutorials for beginners should
>> show a multiple-value return example right at the point where function calls
>> and return values are first explained.
>>
>> I really do not understand why the earlier implementation of "multiple-value
>> returns" was deprecated. then again, I am a naive end user, not a computer
>> language expert. I probably would not even understand the nuances of syntax
>> ambiguities that may have arisen. (this is my shortcoming.)
>>
>> regards,
>>
>> /iaw
>>
>>
>> On Mar 7, 2009 4:34am, Wacek Kusnierczyk
>> wrote:
>>> mark.braving...@csiro.au wrote:
>>>
>>> >
>>>
>>> >> The syntax for returning multiple arguments does not strike me as
>>>
>>> >> particularly appealing. would it not possible to allow syntax like:
>>>
>>> >>
>>>
>>> >> f= function() { return( rnorm(10), rnorm(20) ) }
>>>
>>> >> (a,d$b) = f()
>>>
>>> >>
>>>
>>> >>
>>>
>>> >
>>>
>>> >
>>>
>>> > FWIW, my own solution is to define a "multi-assign operator":
>>>
>>> >
>>>
>>> > '%
>>> > # a must be of the form '{thing1;thing2;...}'
>>>
>>> > a
>>> > e
>>> > stopifnot( length( b) == length( a))
>>>
>>> > for( i in seq_along( a))
>>>
>>> > eval( call( '
>>> > NULL
>>>
>>> > }
>>>
>>> >
>>>
>>>
>>>
>>> you might want to have the check less stringent, so that rhs may consist
>>>
>>> of more values that the lhs has variables. or even skip the check and
>>>
>>> assign NULL to a[i] for i > length(b). another idea is to allow %
>>> be used with just one variable on the lhs.
>>>
>>>
>>>
>>> here's a modified version:
>>>
>>>
>>>
>>> '%
>>> a
>>> if (length(a) > 1)
>>>
>>> a
>>> if (length(a) > length(b))
>>>
>>> b
>>> e
>>> for( i in seq_along( a))
>>>
>>> eval( call( '
>>> NULL }
>>>
>>>
>>>
>>> {a; b} %
>>> # a = 1; b = 2
>>>
>>> a %
>>> # a = 3
>>>
>>> {a; b} %
>>> # a = 5; b = NULL
>>>
>>>
>>>
>>>
>>>
>>> vQ
>>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 9:38 AM, ivo welch wrote:
> hi gabor: this would be difficult to do. I don't think you want to
> read my programs. it would give you an appreciation of what ugly
> horror programs end users can write in the beautiful R language ;-).
>
> clearly, one can work around the lack of such a feature.
> multiple-return values are syntax sugar. but maybe it helps to
> explain how I got to my own view. I had to send an R program to
> someone who had never used it before. without knowing R, he could
> literally read the entire program. the only thing that stumped him
> was the multiple return values. In my program, he saw
>
> f= function() { return(list(a=myvector1, b=myvector2)) }
>
> result=f()
> a= result$a
> b= result$a
> rm(result)
>
> I had picked this method up over the years reading r-help. of course,
> I had 10 return values, not two, each return value with its own long
> name. I think it would have been a whole lot nicer if I could have
> written FOR HIM simply
>
> f= function() { return(myvector1,myvector2); }
> (a,b)= f()
The function would be better written
f <- function() list(a = myvector1, b = myvector2)
and then called:
L <- f()
>
> again, its syntax sugar. I would find such syntax a whole lot more
> appealing. and I often write functions that pass back a main program,
> but also some debug or other information. maybe I am the only one...
>
> regards,
>
> /iaw
>
>
> On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
> wrote:
>> Why? Can you demonstrate any situations where its useful? Despite
>> having my own facility for this I've found that over the years I
>> have never used it.
>>
>> On Sat, Mar 7, 2009 at 9:23 AM, wrote:
>>> Gentlemen---these are all very clever workarounds, but please forgive me for
>>> voicing my own opinion: IMHO, returning multiple values in a statistical
>>> language should really be part of the language itself. there should be a
>>> standard syntax of some sort, whatever it may be, that everyone should be
>>> able to use and which easily transfers from one local computer to another.
>>> It should not rely on clever hacks in the .Rprofile that are different from
>>> user to user, and which leave a reader of end user R code baffled at first
>>> by all the magic that is going on. Even the R tutorials for beginners should
>>> show a multiple-value return example right at the point where function calls
>>> and return values are first explained.
>>>
>>> I really do not understand why the earlier implementation of "multiple-value
>>> returns" was deprecated. then again, I am a naive end user, not a computer
>>> language expert. I probably would not even understand the nuances of syntax
>>> ambiguities that may have arisen. (this is my shortcoming.)
>>>
>>> regards,
>>>
>>> /iaw
>>>
>>>
>>> On Mar 7, 2009 4:34am, Wacek Kusnierczyk
>>> wrote:
mark.braving...@csiro.au wrote:
>
>> The syntax for returning multiple arguments does not strike me as
>> particularly appealing. would it not possible to allow syntax like:
>>
>> f= function() { return( rnorm(10), rnorm(20) ) }
>> (a,d$b) = f()
>>
>>
>
>
> FWIW, my own solution is to define a "multi-assign operator":
>
> '%
> # a must be of the form '{thing1;thing2;...}'
> a
> e
> stopifnot( length( b) == length( a))
> for( i in seq_along( a))
> eval( call( '
> NULL
> }
>
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i > length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) > 1)
a
if (length(a) > length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Follow-up on the wish for a visibility flag with tryEval ?
Dear list, Did the wish for an official API for evaluating expressions while keeping an eye on the R_Visible flag (see: https://stat.ethz.ch/pipermail/r-devel/2007-April/045258.html ) lead to something ? I could not find a sign of it the current (R-2.8.1 and R-2.9-dev) R defines. Thanks, L. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
ivo...@gmail.com wrote: > Gentlemen---these are all very clever workarounds, hacks around the lack of a feature > but please forgive me for voicing my own opinion: IMHO, returning > multiple values in a statistical language should really be part of the > language itself. returning multiple values is supported by many programming languages, in particular scripting languages. while in r you can use the %<-% hack or have functions return lists of values, it could indeed be useful to have such a feature in a statistical language like r. > there should be a standard syntax of some sort, if you mean that r should have such a syntax, you're likely to learn more about saying 'should' soon. > whatever it may be, that everyone should be able to use and which > easily transfers from one local computer to another. It should not > rely on clever hacks in the .Rprofile that are different from user to > user, and which leave a reader of end user R code baffled at first by > all the magic that is going on. Even the R tutorials for beginners > should show a multiple-value return example right at the point where > function calls and return values are first explained. as gabor says in another post, you probably should first show why having multiple value returns would be useful in r. however, i don't think there are good counterarguments anyway, and putting on you the burden of proving a relatively obvious (or not so?) thing is a weak escape. to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some discussion and examples. vQ [1] Design Concepts in Programming Languages, Turbak and Gifford with Sheldon, MIT 2008 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 10:26 AM, Wacek Kusnierczyk wrote: > ivo...@gmail.com wrote: >> Gentlemen---these are all very clever workarounds, > > hacks around the lack of a feature > >> but please forgive me for voicing my own opinion: IMHO, returning >> multiple values in a statistical language should really be part of the >> language itself. > > returning multiple values is supported by many programming languages, in > particular scripting languages. while in r you can use the %<-% hack or > have functions return lists of values, it could indeed be useful to > have such a feature in a statistical language like r. > > >> there should be a standard syntax of some sort, > > if you mean that r should have such a syntax, you're likely to learn > more about saying 'should' soon. > >> whatever it may be, that everyone should be able to use and which >> easily transfers from one local computer to another. It should not >> rely on clever hacks in the .Rprofile that are different from user to >> user, and which leave a reader of end user R code baffled at first by >> all the magic that is going on. Even the R tutorials for beginners >> should show a multiple-value return example right at the point where >> function calls and return values are first explained. > > as gabor says in another post, you probably should first show why having > multiple value returns would be useful in r. however, i don't think > there are good counterarguments anyway, and putting on you the burden of > proving a relatively obvious (or not so?) thing is a weak escape. > > to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some > discussion and examples. > The fact that other languages is an argument for further consideration but not a definitive argument for it. I have had this feature for years via my workaround yet I never use it which seems a good argument against it. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Gabor Grothendieck wrote:
> On Sat, Mar 7, 2009 at 9:38 AM, ivo welch wrote:
>
>> hi gabor: this would be difficult to do. I don't think you want to
>> read my programs. it would give you an appreciation of what ugly
>> horror programs end users can write in the beautiful R language ;-).
>>
>> clearly, one can work around the lack of such a feature.
>> multiple-return values are syntax sugar. but maybe it helps to
>> explain how I got to my own view. I had to send an R program to
>> someone who had never used it before. without knowing R, he could
>> literally read the entire program. the only thing that stumped him
>> was the multiple return values. In my program, he saw
>>
>> f= function() { return(list(a=myvector1, b=myvector2)) }
>>
>> result=f()
>> a= result$a
>> b= result$a
>> rm(result)
>>
>> I had picked this method up over the years reading r-help. of course,
>> I had 10 return values, not two, each return value with its own long
>> name. I think it would have been a whole lot nicer if I could have
>> written FOR HIM simply
>>
>> f= function() { return(myvector1,myvector2); }
>> (a,b)= f()
>>
>
> The function would be better written
>
> f <- function() list(a = myvector1, b = myvector2)
>
> and then called:
>
> L <- f()
>
that's exactly what ivo shows above, with an explanation of why he finds
it inconvenient.
one point that could be made in favour of multiple return values is that
when you return a list, you a) have a nuissance object, some of whose
components may not be of interest at all, and b) elongate the value
lookup path (list$variable vs. variable), both of which add performance
penalty -- which is surely negligible in many cases.
you can of course use with, as here:
with(f(),
)
which rather remotely resembles call-with-values in scheme or receive in
guile, but this adds a penalty again (with constructs a new local
environment) and makes the code less readable. it also suffers from the
same problem as accessing the variables explicitly from the returned
list (as l$a, for example), namely, that the variable names are as given
by the author rather than the user of the function.
i have had occasions where it would be convenient to be able to do
something like
c(first, last) = f(...)[1, 4]
or
c(left, right) = f(...)[c('u.glyNAME', 'uninformative.name')]
as to the usefulness of capturing multiple return values each in a
variable on its own, it's really at the heart of perl, where you can
capture the return either into an array variable or into a collection of
scalar (and array) variables:
@values = &function(...)
($first, $second, @rest) = function(...)
but of course, r is not perl and vice versa, so this is a red herring
argument.
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Gabor Grothendieck wrote: > >> as gabor says in another post, you probably should first show why having >> multiple value returns would be useful in r. however, i don't think >> there are good counterarguments anyway, and putting on you the burden of >> proving a relatively obvious (or not so?) thing is a weak escape. >> >> to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some >> discussion and examples. >> >> > > The fact that other languages is an argument for further consideration > but not a definitive argument for it. > of course! > I have had this feature for years via my workaround yet I never > use it which seems a good argument against it. > the fact that another programmer is an argument for further consideration but not a definitive argument against it. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 11:37 AM, Wacek Kusnierczyk
wrote:
> Gabor Grothendieck wrote:
>>
>>> as gabor says in another post, you probably should first show why having
>>> multiple value returns would be useful in r. however, i don't think
>>> there are good counterarguments anyway, and putting on you the burden of
>>> proving a relatively obvious (or not so?) thing is a weak escape.
>>>
>>> to call for a reference, sec. 9.2.3, p. 450+ in [1] provides some
>>> discussion and examples.
>>>
>>>
>>
>> The fact that other languages is an argument for further consideration
>> but not a definitive argument for it.
>>
>
> of course!
>
>> I have had this feature for years via my workaround yet I never
>> use it which seems a good argument against it.
>>
>
> the fact that another programmer is an argument for further
> consideration but not a definitive argument against it.
I've provided an argument against it and no one has provided one
for it. The so-called identical code Ivo showed was not identical
and, in fact, was flawed. Your first/last example could be
written:
f <- function() letters
L <- structure(f()[1:2], names = c("first", "last"))
or one could define a function to do that without having
to modify the language. Given the relative infrequency
of this it hardly seems to merit a language feature.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
One idea of program design is that users
should be protected against themselves.
It is my experience that users, especially
novices, tend to over-split items rather than
over-clump items. The fact that items are
returned by the same function call would
argue to me that there is a connection between
the items.
Patrick Burns
patr...@burns-stat.com
+44 (0)20 8525 0696
http://www.burns-stat.com
(home of "The R Inferno" and "A Guide for the Unwilling S User")
ivo welch wrote:
hi gabor: this would be difficult to do. I don't think you want to
read my programs. it would give you an appreciation of what ugly
horror programs end users can write in the beautiful R language ;-).
clearly, one can work around the lack of such a feature.
multiple-return values are syntax sugar. but maybe it helps to
explain how I got to my own view. I had to send an R program to
someone who had never used it before. without knowing R, he could
literally read the entire program. the only thing that stumped him
was the multiple return values. In my program, he saw
f= function() { return(list(a=myvector1, b=myvector2)) }
result=f()
a= result$a
b= result$a
rm(result)
I had picked this method up over the years reading r-help. of course,
I had 10 return values, not two, each return value with its own long
name. I think it would have been a whole lot nicer if I could have
written FOR HIM simply
f= function() { return(myvector1,myvector2); }
(a,b)= f()
again, its syntax sugar. I would find such syntax a whole lot more
appealing. and I often write functions that pass back a main program,
but also some debug or other information. maybe I am the only one...
regards,
/iaw
On Sat, Mar 7, 2009 at 9:28 AM, Gabor Grothendieck
wrote:
Why? Can you demonstrate any situations where its useful? Despite
having my own facility for this I've found that over the years I
have never used it.
On Sat, Mar 7, 2009 at 9:23 AM, wrote:
Gentlemen---these are all very clever workarounds, but please forgive me for
voicing my own opinion: IMHO, returning multiple values in a statistical
language should really be part of the language itself. there should be a
standard syntax of some sort, whatever it may be, that everyone should be
able to use and which easily transfers from one local computer to another.
It should not rely on clever hacks in the .Rprofile that are different from
user to user, and which leave a reader of end user R code baffled at first
by all the magic that is going on. Even the R tutorials for beginners should
show a multiple-value return example right at the point where function calls
and return values are first explained.
I really do not understand why the earlier implementation of "multiple-value
returns" was deprecated. then again, I am a naive end user, not a computer
language expert. I probably would not even understand the nuances of syntax
ambiguities that may have arisen. (this is my shortcoming.)
regards,
/iaw
On Mar 7, 2009 4:34am, Wacek Kusnierczyk
wrote:
mark.braving...@csiro.au wrote:
The syntax for returning multiple arguments does not strike me as
particularly appealing. would it not possible to allow syntax like:
f= function() { return( rnorm(10), rnorm(20) ) }
(a,d$b) = f()
FWIW, my own solution is to define a "multi-assign operator":
'%
# a must be of the form '{thing1;thing2;...}'
a
e
stopifnot( length( b) == length( a))
for( i in seq_along( a))
eval( call( '
NULL
}
you might want to have the check less stringent, so that rhs may consist
of more values that the lhs has variables. or even skip the check and
assign NULL to a[i] for i > length(b). another idea is to allow %
be used with just one variable on the lhs.
here's a modified version:
'%
a
if (length(a) > 1)
a
if (length(a) > length(b))
b
e
for( i in seq_along( a))
eval( call( '
NULL }
{a; b} %
# a = 1; b = 2
a %
# a = 3
{a; b} %
# a = 5; b = NULL
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Patrick Burns wrote: One idea of program design is that users should be protected against themselves. It is my experience that users, especially novices, tend to over-split items rather than over-clump items. The fact that items are returned by the same function call would argue to me that there is a connection between the items. Patrick Burns patr...@burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of "The R Inferno" and "A Guide for the Unwilling S User") Hi Gabor, Patrick, Ivo and vQ, I agree with Patrick and Gabor that it is not needed. IMHO it is good design that a function (in a mathematical sense) returns ONE object, let it a single value, a list or an S3/S4 object. This can be passed to another function as a whole or can be splitted to its parts according to different needs. If only single parts are required, than I would suggest to use accessor functions preferably written as generics working on returned S3 or S4 objects. I'm strongly against going back to the past S behaviour and I wonder a little bit about this discussion. I like it to have a clean workspace with only a few objects. Thomas Petzoldt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Gabor Grothendieck wrote:
>
> I've provided an argument against it and no one has provided one
> for it. The so-called identical code Ivo showed was not identical
> and, in fact, was flawed.
no, you're wrong. you think of the part where ivo shows what he'd like
to have; the example i was referring to was almost identical with
yours, except for the explicit return and '=' used for assignment.
> Your first/last example could be
> written:
>
> f <- function() letters
> L <- structure(f()[1:2], names = c("first", "last"))
>
indeed, but:
- this still does not allow one to use the names directly, only as
L$first etc., with the syntactic and semantic (longer lookup times) penalty;
- using structure you add yet another source of performance penalty; a
quick naive benchmark hints that it doubles the time elapsed if the
returned list is inaccessible otherwise, and adds one order of magnitude
if the list has to be copied:
f1= function() as.list(letters)
f2 =local({ letters = as.list(letters); function() letters })
source('http://rbenchmark.googlecode.com/svn/trunk/benchmark.r')
benchmark(replications=1, columns=c('test', 'elapsed'),
'f1 direct'=f1(),
'f1 structure'=structure(f1(), names=letters),
'f2 direct'=f2(),
'f2 structure'=structure(f2(), names=letters))
# test elapsed
# 1f1 direct 0.171
# 2 f1 structure 0.693
# 3f2 direct 0.048
# 4 f2 structure 0.594
instead of a syntactically (and semantically, if done appropriately)
clean solution:
c(a, b) = f()[1,3]
# work with a and b
you offer a glut:
l = structure(f()[1,3], names=c('a', 'b'))
# work with l$a and l$b
> or one could define a function to do that without having
> to modify the language. Given the relative infrequency
> of this it hardly seems to merit a language feature.
>
infrequency of what? of people's inventing ugly hacks to get arround
the inability to capture multiple return values directly? sure, this is
a good argument against having someone do the job, but is it a good
argument against having the feature in the language?
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
On Sat, Mar 7, 2009 at 3:19 PM, Wacek Kusnierczyk
wrote:
> Gabor Grothendieck wrote:
>>
>> I've provided an argument against it and no one has provided one
>> for it. The so-called identical code Ivo showed was not identical
>> and, in fact, was flawed.
>
> no, you're wrong. you think of the part where ivo shows what he'd like
> to have; the example i was referring to was almost identical with
> yours, except for the explicit return and '=' used for assignment.
>
>
>> Your first/last example could be
>> written:
>>
>> f <- function() letters
>> L <- structure(f()[1:2], names = c("first", "last"))
>>
>
> indeed, but:
>
> - this still does not allow one to use the names directly, only as
> L$first etc., with the syntactic and semantic (longer lookup times) penalty;
That's how it should be done. Using the auto split you get many
variables which is not desirable. it encourages bad programming.
>
> - using structure you add yet another source of performance penalty; a
> quick naive benchmark hints that it doubles the time elapsed if the
> returned list is inaccessible otherwise, and adds one order of magnitude
> if the list has to be copied:
There is no difference between structure and assignment. They are both
operations. If there is a timing difference that is a different question.
>
> f1= function() as.list(letters)
> f2 =local({ letters = as.list(letters); function() letters })
>
> source('http://rbenchmark.googlecode.com/svn/trunk/benchmark.r')
> benchmark(replications=1, columns=c('test', 'elapsed'),
> 'f1 direct'=f1(),
> 'f1 structure'=structure(f1(), names=letters),
> 'f2 direct'=f2(),
> 'f2 structure'=structure(f2(), names=letters))
>
> # test elapsed
> # 1 f1 direct 0.171
> # 2 f1 structure 0.693
> # 3 f2 direct 0.048
> # 4 f2 structure 0.594
>
> instead of a syntactically (and semantically, if done appropriately)
> clean solution:
>
> c(a, b) = f()[1,3]
> # work with a and b
>
> you offer a glut:
>
> l = structure(f()[1,3], names=c('a', 'b'))
> # work with l$a and l$b
>
>
>> or one could define a function to do that without having
>> to modify the language. Given the relative infrequency
>> of this it hardly seems to merit a language feature.
>>
>
> infrequency of what? of people's inventing ugly hacks to get arround
> the inability to capture multiple return values directly? sure, this is
> a good argument against having someone do the job, but is it a good
> argument against having the feature in the language?
I have never had to use it even though I had it available for years.
I do lots of R code so I think it speaks for itself.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Gabor Grothendieck wrote: > >> - this still does not allow one to use the names directly, only as >> L$first etc., with the syntactic and semantic (longer lookup times) penalty; >> > > That's how it should be done. Using the auto split you get many > variables which is not desirable. it encourages bad programming. > > please provide a reference for this claim. for both the 'should' and the 'bad'. >> - using structure you add yet another source of performance penalty; a >> quick naive benchmark hints that it doubles the time elapsed if the >> returned list is inaccessible otherwise, and adds one order of magnitude >> if the list has to be copied: >> > > There is no difference between structure and assignment. They are both > operations. If there is a timing difference that is a different question. > as far as i get the r semantics, applying structure modifies the object, and causes the content to be copied if the object is referred to from elsewhere. here's where structure does add a considerable performance penalty. > >>> or one could define a function to do that without having >>> to modify the language. Given the relative infrequency >>> of this it hardly seems to merit a language feature. >>> >>> >> infrequency of what? of people's inventing ugly hacks to get arround >> the inability to capture multiple return values directly? sure, this is >> a good argument against having someone do the job, but is it a good >> argument against having the feature in the language? >> > > I have never had to use it even though I had it available for years. > I do lots of R code so I think it speaks for itself. > it speaks for yourself. it tells nothing about what others would like. it's quite possible that few would like it, but it does not follow from that you wouldn't. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Follow-up on the wish for a visibility flag with tryEval ?
On 07/03/2009 9:51 AM, Laurent Gautier wrote: Dear list, Did the wish for an official API for evaluating expressions while keeping an eye on the R_Visible flag (see: https://stat.ethz.ch/pipermail/r-devel/2007-April/045258.html ) lead to something ? I could not find a sign of it the current (R-2.8.1 and R-2.9-dev) R defines. You should read the NEWS file, where you'll find withVisible mentioned. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question
Thomas Petzoldt wrote: > Patrick Burns wrote: >> One idea of program design is that users >> should be protected against themselves. ... and r coherently implements this idea :] >> >> It is my experience that users, especially >> novices, tend to over-split items rather than >> over-clump items. The fact that items are >> returned by the same function call would >> argue to me that there is a connection between >> the items. >> >> >> Patrick Burns >> patr...@burns-stat.com >> +44 (0)20 8525 0696 >> http://www.burns-stat.com >> (home of "The R Inferno" and "A Guide for the Unwilling S User") > > Hi Gabor, Patrick, Ivo and vQ, hello thomas, > > I agree with Patrick and Gabor that it is not needed. IMHO it is good > design that a function (in a mathematical sense) returns ONE object, > let it a single value, a list or an S3/S4 object. in r functions are not functions in the mathematical sense. r is not quite a functional programming language, though it's certainly closer to fp than c or fortran, say. if one were really interested in whether the feature is desired as a convenience rather than in enforcing one's own opinion, one'd ask users. it's certainly not *needed* in the sense that you can do without it -- but then there are many more features in r which are not needed (and some of them are more harmful than multiple return values would be). > This can be passed to another function as a whole or can be splitted > to its parts according to different needs. right, but that's extra work with coding and performance penalty. > If only single parts are required, than I would suggest to use > accessor functions preferably written as generics working on returned > S3 or S4 objects. I'm strongly against going back to the past S > behaviour and I wonder a little bit about this discussion. i don't know that s behaviour, it's quite possible that it was really wrong. but the fact that s had it wrong (if it did) does not mean that multiple return values are wrong per se. > I like it to have a clean workspace with only a few objects. why would letting others choose for themselves be a bad idea? that's what perl, python, ruby, or more recent languages such as scala, do -- functions can return (tuples of) multiple values which you can capture separately and/or collectively. multiple assignment is a fairly common feature in modern programming languages. it seems that this is a remote dream in r, because 'users should be protected against themselves'. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in qpois help (PR#13583)
Full_Name: Manikandan Narayanan Version: 2.8.1 OS: Linux Submission from: (NULL) (155.91.45.231) Here is an excerpt from qpois help page (?qpois): The quantile is left continuous: 'qgeom(q, prob)' is the largest integer x such that P(X <= x) < q. I think the "qgeom" here should be "qpois" instead. Please correct this typo in ?qpois, since it's misleading in its current form. Thanks! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
