From oliver at first.in-berlin.de  Thu Mar  8 16:39:51 2012
From: oliver at first.in-berlin.de (oliver)
Date: Thu, 8 Mar 2012 16:39:51 +0100
Subject: [Rd] Julia
In-Reply-To: <20120308135624.GA9947@siouxsie>
References: <E66794E69CFDE04D9A70842786030B93282DF1@PA-MBX04.na.tibco.com>
	<20120305170835.GA4134@siouxsie> <4F555343.8020007@fhcrc.org>
	<E66794E69CFDE04D9A70842786030B932831A9@PA-MBX04.na.tibco.com>
	<20120306091143.GC1849@siouxsie>
	<E66794E69CFDE04D9A70842786030B932834C7@PA-MBX04.na.tibco.com>
	<CADUbQ5j-d2EcaqNU1cQN3SEEheF7YB+KV0==4iu8XkQbbytCnw@mail.gmail.com>
	<20120307182139.GA5564@siouxsie>
	<E66794E69CFDE04D9A70842786030B93283D0F@PA-MBX04.na.tibco.com>
	<20120308135624.GA9947@siouxsie>
Message-ID: <20120308153951.GA11755@siouxsie>

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: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



[Rd] Julia
oliver