Ah, and you mean if it's an anonymous array
it could be reused directly from the args.
OK, now I see why you insist on the anonymous data thing.
I didn't grasped it even in my last mail.
But that somehow also relates to what I wrote about reusing an already
existing, named vector.
Just the moment of in-place-modification is different.
From
x <- runif(n)
cx <- cos(x)
instead of
> > cx <- cos(x=runif(n)) # no allocation needed, use the input space for
> > the return value
to something like
cx <- runif(n)
cos( cx, inplace=TRUE)
or
cos( runif(n), inplace=TRUE)
This way it would be possible to specify the reusage
of the input *explicitly* (without implicit rules
like anonymous vs. named values).
In Pseudo-Code something like that:
if (in_place == TRUE )
{
input_val[idx] = cos( input_val[idx] );
return input_val;
}
else
{
result_val = alloc_vec( LENGTH(input_val), ... );
result_val[idx] = cos( input_val[idx] );
return result_val;
}
Is this matching, what you were looking for?
Ciao,
Oliver
On Thu, Mar 08, 2012 at 02:56:24PM +0100, oliver wrote:
> Hi,
>
> ok, thank you for clarifiying what you meant.
> You only referred to the reusage of the args,
> not of an already existing vector.
> So I overgenerealized your example.
>
> But when looking at your example,
> and how I would implement the cos()
> I doubt I would use copying the args
> before calculating the result.
>
> Just allocate a result-vector, and then place the cos()
> of the input-vector into the result vector.
>
> I didn't looked at how it is done in R,
> but I would guess it's like that.
>
>
> In pseudo-Code something like that:
> cos_val[idx] = cos( input_val[idx] );
>
> But R also handles complex data with cos()
> so it will look a bit more laborious.
>
> What I have seen so far from implementing C-extensions
> for R is rather C-ish, and so you have the control
> on many details. Copying the input just to read it
> would not make sense here.
>
> I doubt that R internally is doing that.
> Or did you found that in the R-code?
>
> The other problem, someone mentioned, was *changing* the contents
> of a matrix... and that this is NO>T done in-place, when using
> a function for it.
> But the namespace-name / variable-name as "references" to the matrix
> might solve that problem.
>
>
> Ciao,
> Oliver
>
>
>
> On Wed, Mar 07, 2012 at 07:10:43PM +0000, William Dunlap wrote:
> > No my examples are what I meant. My point was that a function, say cos(),
> > can act like it does call-by-value but conserve memory when it can if it
> > can
> > distinguish between the case
> > cx <- cos(x=runif(n)) # no allocation needed, use the input space for
> > the return value
> > and and the case
> > x <- runif(n)
> > cx <- cos(x=x) # return value cannot reuse the argument's memory, so
> > allocate space for return value
> > sum(x) # Otherwise sum(x) would return sum(cx)
> > The function needs to know if a memory block is referred to by a name in
> > any environment
> > in order to do that.
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >
> > > -----Original Message-----
> > > From: oliver [mailto:oli...@first.in-berlin.de]
> > > Sent: Wednesday, March 07, 2012 10:22 AM
> > > To: Dominick Samperi
> > > Cc: William Dunlap; R-devel
> > > Subject: Re: [Rd] Julia
> > >
> > > On Tue, Mar 06, 2012 at 12:49:32PM -0500, Dominick Samperi wrote:
> > > > On Tue, Mar 6, 2012 at 11:44 AM, William Dunlap <wdun...@tibco.com>
> > > wrote:
> > > > > S (and its derivatives and successors) promises that functions will
> > > > > not change their arguments, so in an expression like
> > > > > val <- func(arg)
> > > > > you know that arg will not be changed. You can do that by having
> > > > > func copy arg before doing anything, but that uses space and time
> > > > > that you want to conserve.
> > > > > If arg is not a named item in any environment then it should be fine
> > > > > to write over the original because there is no way the caller can
> > > > > detect that shortcut. E.g., in
> > > > > cx <- cos(runif(n))
> > > > > the cos function does not need to allocate new space for its output,
> > > > > it can just write over its input because, without a name attached to
> > > > > it, the caller has no way of looking at what runif(n) returned. If
> > > > > you did
> > > > > x <- runif(n)
> > > > > cx <- cos(x)
> > >
> > > You have two names here, x and cx, hence your example does not fit into
> > > what
> > > you want to explain.
> > >
> > > A better example would be:
> > > x <- runif(n)
> > > x <- cos(x)
> > >
> > >
> > >
> > > > > then cos would have to allocate new space for its output because
> > > > > overwriting its input would affect a subsequent
> > > > > sum(x)
> > > > > I suppose that end-users and function-writers could learn to live
> > > > > with having to decide when to copy, but not having to make that
> > > > > decision makes S more pleasant (and safer) to use.
> > > > > I think that is a major reason that people are able to share S code
> > > > > so easily.
> > > >
> > > > But don't forget the "Holy Grail" that Doug mentioned at the start of
> > > > this thread: finding a flexible language that is also fast. Currently
> > > > many R packages employ C/C++ components to compensate for the fact
> > > > that the R interpreter can be slow, and the pass-by-value semantics of
> > > > S provides no protection here.
> > > [...]
> > >
> > > The distinction imperative vs. functional has nothing to do with the
> > > distinction
> > > interpreted vs. directly executed.
> > >
> > >
> > >
> > >
> > > Thinking again on the problem that was mentioned here, I think it might be
> > > circumvented.
> > >
> > > Looking again at R's properties, looking again into U.Ligges
> > > "Programmieren in
> > > R", I saw there was mentioned that in R anything (?!) is an object... so
> > > then it's
> > > OOP; but also it was mentioned, R is a functional language. But this does
> > > not
> > > mean it's purely functional or has no imperative data structures.
> > >
> > > As R relies heavily on vectors, here we have an imperative datastructure.
> > >
> > > So, it rather looks to me that "<-" does work in-place on the vectors,
> > > even "<-"
> > > itself is a function (which does not matter for the problem).
> > >
> > > If thats true (I assume here, it is; correct me, if it's wrong), then I
> > > think, assigning
> > > with "<<-" and assign() also would do an imperative
> > > (in-place) change of the contents.
> > >
> > > Then the copying-of-big-objects-when-passed-as-args problem can be
> > > circumvented by working on either a variable in the GlobalEnv (and using
> > > "<<-",
> > > or using a certain environment for the big data and passing it's name
> > > (and the
> > > variable) as value to the function which then uses assign() and get() to
> > > work on
> > > that data.
> > > Then in-place modification should be possible.
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > In 2008 Ross Ihaka and Duncan Temple Lang published the paper "Back to
> > > > the Future: Lisp as a base for a statistical computing system" where
> > > > they propose Common Lisp as a new foundation for R. They suggest that
> > > > this could be done while maintaining the same familiar R syntax.
> > > >
> > > > A key requirement of any strategy is to maintain easy access to the
> > > > huge universe of existing C/C++/Fortran numerical and graphics
> > > > libraries, as these libraries are not likely to be rewritten.
> > > >
> > > > Thus there will always be a need for a foreign function interface, and
> > > > the problem is to provide a flexible and type-safe language that does
> > > > not force developers to use another unfamiliar, less flexible, and
> > > > error-prone language to optimize the hot spots.
> > >
> > > If I here "type safe" I rather would think about OCaml or maybe Ada, but
> > > not
> > > LISP.
> > >
> > > Also, LISP has so many "("'s and ")"'s,
> > > that it's making people going crazy ;-)
> > >
> > > Ciao,
> > > Oliver
>
> ______________________________________________
> 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
