Julia
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:oliver at 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 <wdunlap at 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