Re: [Rd] Julia

From: oliver <oliver_at_first.in-berlin.de>
Date: Thu, 08 Mar 2012 14:56:24 +0100

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



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu 08 Mar 2012 - 14:21:42 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 08 Mar 2012 - 15:50:25 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive